Review Request 118238: Support QML import statements

Denis Steckelmacher steckdenis at yahoo.fr
Thu May 22 19:15:16 UTC 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118238/
-----------------------------------------------------------

(Updated May 22, 2014, 7:15 p.m.)


Status
------

This change has been marked as submitted.


Review request for KDevelop.


Repository: kdev-qmljs


Description
-------

This patch adds basic support for import statements in QML files. It uses KStandardDirs to get the plugin.qmltypes file associated with an imported module (these files are installed by the plugin in KDE_DATA/kdevqmljssupport/qmlplugins/Module.qml), and then schedules a parse job for the file if it hasn't yet been parsed. Once the file is parsed, the importing QML file is scheduled for reparse, and the import statements imports the QML module (using addImportedParentContext)

The diff attached to this review request is very big because it adds QML module files for all the QML modules shipped with Qt 5.2 (an update to Qt 5.3 is planned). More fine-grained commits can be found in the "import_statements" branch of kde:scratch/dsteckelmacher. The most interesting changes are the addition of ParseSession::contextOfModule (that parses a module file and returns its TopDUContext) and DeclarationBuilder::visit(UiImport*) (that imports the TopDUContext returned by ParseSession::contextOfModule).


Diffs
-----

  CMakeLists.txt 9e90f99 
  duchain/declarationbuilder.h 265d0ce 
  duchain/declarationbuilder.cpp 10701bd 
  duchain/parsesession.h 0facef4 
  duchain/parsesession.cpp 998e5b0 
  qmlplugins/Builtins1.qml PRE-CREATION 
  qmlplugins/Builtins2.qml PRE-CREATION 
  qmlplugins/CMakeLists.txt PRE-CREATION 
  qmlplugins/Qt.labs.folderlistmodel.qml PRE-CREATION 
  qmlplugins/Qt.labs.gestures.qml PRE-CREATION 
  qmlplugins/Qt.labs.particles.qml PRE-CREATION 
  qmlplugins/Qt.labs.settings.qml PRE-CREATION 
  qmlplugins/Qt.labs.shaders.qml PRE-CREATION 
  qmlplugins/QtAudioEngine.qml PRE-CREATION 
  qmlplugins/QtBluetooth.qml PRE-CREATION 
  qmlplugins/QtMultimedia.qml PRE-CREATION 
  qmlplugins/QtNfc.qml PRE-CREATION 
  qmlplugins/QtPositioning.qml PRE-CREATION 
  qmlplugins/QtQuick.Controls.qml PRE-CREATION 
  qmlplugins/QtQuick.Dialogs.qml PRE-CREATION 
  qmlplugins/QtQuick.Layouts.qml PRE-CREATION 
  qmlplugins/QtQuick.LocalStorage.qml PRE-CREATION 
  qmlplugins/QtQuick.Particles.qml PRE-CREATION 
  qmlplugins/QtQuick.PrivateWidgets.qml PRE-CREATION 
  qmlplugins/QtQuick.Window.qml PRE-CREATION 
  qmlplugins/QtQuick.XmlListModel.qml PRE-CREATION 
  qmlplugins/QtQuick.qml PRE-CREATION 
  qmlplugins/QtSensors.qml PRE-CREATION 
  qmlplugins/QtTest.qml PRE-CREATION 
  qmlplugins/importplugins.sh PRE-CREATION 
  tests/files/test.qml 605716d 
  tests/test_files.cpp 1130112 

Diff: https://git.reviewboard.kde.org/r/118238/diff/


Testing
-------

Manual testing in KDevelop shows that everything works as expected. While the code-completion is not yet able to list the components exported by a module (this is the object of a future patch), the Text component of the following code snippet is recognized as being an instance of "Module::QDeclarativeText":

import QtQuick 1.0

Text {
    id: foo
}

Text is recognized as Module::QDeclarativeText because the declarations of module components are not yet properly namespaced. Moreover, QML components declare C++-ish names (QDeclarativeText), and the QML names are listed in "exports" properties and are handled by the QML/JS plugin like type aliases. This is not very user friendly and is subject to changes now that import statements are supported.

-- (for historical reasons, here is a problem that is now solved) --

The unit tests segfault when they have to parse a file containing an import. The crash always happens in an openDeclaration() or currentDeclaration() call, and if I comment the faulting call, another one will crash. The crash does not happen anymore if I remove the calls to "bgparser->addDocument" added in this patch, and does not happen in a complete KDevelop instance.

I'm therefore wondering how the background parser can interact with openDeclaration(). I've checked and a DUChainReadLock or a DUChainWriteLock is always held when openDeclaration() is called, but maybe there are other locks that may be needed. I turn to more advanced KDevelop developers on this matter.


Thanks,

Denis Steckelmacher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140522/2fc0734f/attachment-0001.html>


More information about the KDevelop-devel mailing list