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