Review Request 118575: QML components can only see the declarations of their base classes and in the top-level context, not their parents

[Denis Steckelmacher]

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

Review request for KDevelop.


Repository: kdev-qmljs


Description
-------

QML has very strange visibility rules. Here is an example:

import QtQuick.Controls 1.1

Label {
  id: label
  text: "Hello"

  Button {
    id: button
    onClick: { label.hello = "World"; }
  }
}

"button" is an object that is declared inside label, and thus has an inner context that is a child of the context of "label". However, "button" cannot see the "text" property of "label", even if this property is declared in a parent context. "button" can see "label", though, as "label" is declared in the top-level context (using Declaration::setContext, this was already the case without this patch).

The inner context of a QML object therefore must be able to see the top-level context, its imported parent contexts (class inheritance), but not its parent context. This patch handles that by introducing QmlDUContext, a subclass of DUContext. QmlDUContext provides a method that allows DeclarationBuilder to specify that a context should be blind to its parent (but not the top-level context, hence the addImportedParentContext(topContext()) call).


Diffs
-----

  codecompletion/tests/qmlcompletiontest.cpp c029ea9 
  duchain/CMakeLists.txt b02a257 
  duchain/declarationbuilder.h 1e6c895 
  duchain/declarationbuilder.cpp ede6407 
  duchain/qmlducontext.h PRE-CREATION 
  duchain/qmlducontext.cpp PRE-CREATION 
  tests/files/test.qml cbe2fa6 

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


Testing
-------

Two new unit tests have been added. The first one ensures that the code-completion doesn't list symbols that should not be visible, and the second one checks that UseBuilder does not see uses where there shouldn't be any.

All the other unit tests still pass, but I'm not very confident of the implementation of QmlDUContext. There were many things to take into consideration, many constructors to implement, a macro that mustn't be forgotten, special setClassId calls, etc. I hope that I haven't missed anything, but I'm not sure (valgrind doesn't complain about anything, though, but I'm afraid of subtle cache-related bugs). No other language support plugin that I know (kdev-clang, kdev-oldcpp, kdev-python, kdev-ruby) subclasses DUContextData (they subclass DUContext, though), so I had no example.


Thanks,

Denis Steckelmacher

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