Review Request 118238: Get the top-level context associated with a QML module

Denis Steckelmacher steckdenis at yahoo.fr
Thu May 22 16:44:42 UTC 2014


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

(Updated May 22, 2014, 4:44 p.m.)


Review request for KDevelop.


Changes
-------

Very big diff also containing the module files and the CMakeLists.txt statements needed to install them. This way, the plugin can find the modules and parse them. I did not thought about it, but the crash cannot be reproduced without these files as it is parsing them that causes the problem.

Thanks for the help :-) .


Repository: kdev-qmljs


Description
-------

This patch adds a method that returns the top-level DUContext associated with a QML plugin. It uses KStandardDirs to get the plugin.qmltypes file associated with the 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 the file has already been parsed, then its top level context is returned. This method will be used to implement import statements. The module files and the complete support for import statements can be found in the "import_statements" of kde:scratch/dsteckelmacher.


Diffs (updated)
-----

  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 

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


Testing
-------

This patch cannot be tested as the method is not yet called, but the support for import statements is already implemented in my kde:scratch/dsteckelmacher repository. Import statements work right in KDevelop, but 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/8597ba6b/attachment.html>


More information about the KDevelop-devel mailing list