Testing when the QML DUchain finished all parsing
Andreas Cord-Landwehr
cordlandwehr at kde.org
Sat Jun 4 06:59:41 UTC 2016
Hey Denis & Milian,
and everyone else who has a good idea about the QML DUchain parser :)
I am looking for a solution for the following problem: I have a small patch
ready that fixes the QtHelp context menu information for QML components and
this code I want to unit test.
My approach starts with the following snippet:
void TestQtHelpPlugin::testDeclarationLookup_QmlComponent()
{
init();
TestFile file("import QtQuick 2.1\n Item { id: foo\n }", "qml");
QVERIFY(file.parseAndWait());
DUChainReadLocker lock;
auto ctx = file.topContext();
QVERIFY(ctx);
QVERIFY(!ctx->findDeclarations(QualifiedIdentifier("Item")).isEmpty());
// omitting the rest, since the last verify statement fails
// actually at this point the context does not contain any QML base types
// but consists only of ids
[...]
}
After a surprisingly long debugging, I have the following hypothesis why the
last check is not succeeding: The QML DUchain parser performs the parse of the
testfile. When reading the import statement, a second parser thread is started
to parse the QtQuick base types and the test file is registered to be re-parsed
once QtQuick2.1 is parsed. Yet, the file.parseAndWait() method only waits for
the first notifyReady() signal, which is emitted after the first parser run over
the test file, and the unit test is directly continued before the test file is
reparsed with known QML basetypes.
Hence my question(s):
- What is the best approach to fix this behavior and get a proper unit test?
- Can I reasonable access the currently running threads of the DUchain to use
that value for determining if all threads are finished?
- Would it be reasonable to add a notifyAllParseThreadsCompled() signal or
something similar?
Cheers,
Andreas
More information about the KDevelop-devel
mailing list