Review Request 118600: Support QML signal declarations

[Denis Steckelmacher]

> On June 6, 2014, 9:06 p.m., Milian Wolff wrote:
> > maybe we should check whether we can/should update our internal copy of the QML AST library from QtCreator. Maybe they improved the AST there?

The QML AST library has been updated to QtCreator master (3.1.81 or something like that) approximately three weeks ago. By the way, it solved a big design flaw concerning PropertyNameAndValue (that was PropertyNameAndValueList and had to be manually iterated over), but UiPublicMember wasn't fixed.

Here is the latest Git version of qmljsast_p.h : https://qt.gitorious.org/qt-creator/qt-creator/source/76f829164a5e2a2eb8371dc5dbdd8909b57b21ea:src/libs/qmljs/parser/qmljsast_p.h#L2595 . You can see how inelegant this node is :-) .


- Denis


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


On June 6, 2014, 8:52 p.m., Denis Steckelmacher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118600/
> -----------------------------------------------------------
> 
> (Updated June 6, 2014, 8:52 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-qmljs
> 
> 
> Description
> -------
> 
> This patch adds support for QML signal declarations:
> 
> Item {
>     signal test(int param1, bool param2)
> }
> 
> The patch is not the nicest ever, but the QMLJS AST is especially bad here. First, QML signals and properties are both handled using a single UiPublicMember node (even if they are completely different things), and signals are declared in a completely different mean than Javascript function expressions or plugin.qmltypes signals. There are therefore three ways of declaring a function (a JS function, signals/methods in plugin.qmltypes files and plain QML signals), and the three ways cannot share any code because they use a completely different AST structure (FunctionExpression + FormalParameterList, "Signal { Parameter {...} Parameter {...} }", UiPublicMember + UiParameterList.
> 
> 
> Diffs
> -----
> 
>   duchain/declarationbuilder.cpp 03ae915 
>   tests/files/test.qml d50e737 
> 
> Diff: https://git.reviewboard.kde.org/r/118600/diff/
> 
> 
> Testing
> -------
> 
> Two new unit tests have been added. The first one ensures that signals are properly declared (with their typed parameters), and the second one ensures that the "minimal" syntax for defining signals (without parameters) does not crash. All the other unit tests pass.
> 
> 
> Thanks,
> 
> Denis Steckelmacher
> 
>

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