Review Request 118700: Special handling of the QML "parent" identifier

[Milian Wolff]

> On June 12, 2014, 8:33 p.m., Milian Wolff wrote:
> > duchain/expressionvisitor.cpp, line 200
> > <https://git.reviewboard.kde.org/r/118700/diff/2/?file=280573#file280573line200>
> >
> >     use QmlJS::Document::Language here instead
> >     
> >     also, the access pattern is broken, you first have to lock the duchain, then look at m_context->...
> >     
> >     Maybe you added more of these issues elsewhere? please double-check!
> 
> Sven Brauch wrote:
>     But you're holding the URL lock for that top context, right? So what would happen to it if you access it that way?
> 
> Sven Brauch wrote:
>     As discussed in IRC, nobody knows for sure if this is safe ;) so it's probably better to hold the lock.
> 
> Denis Steckelmacher wrote:
>     Regarding QmlJS::Document::Language, all ExpressionVisitor has is a DUContext (from which a TopDUContext can be retrieved), but QmlJS::Document::Language is only used in ParseSession, that doesn't seem to be stored somewhere (it is instantiated on the stack in QmlJsParseJob and is never stored anywhere else).
>     
>     I was looking at parsing environments (ParsingEnvironmentFile and ParsingEnvironment), but adding a new parsing environment type and a new subclass of ParsingEnvironment seems a bit complex just to avoid half a dozen byteArray() calls ("parent" is never used in big plugin.qmltypes files and only rarely used in normal QML files). Do you have any suggestion on how I can get back the language of the file?

Ah I see, this is for code completion. Hm... Then at least use QmlJS::Document::guessLanguageFromSuffix 


- Milian


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


On June 13, 2014, 10:02 a.m., Denis Steckelmacher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118700/
> -----------------------------------------------------------
> 
> (Updated June 13, 2014, 10:02 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-qmljs
> 
> 
> Description
> -------
> 
> This patch adds a special-case for "parent" in ExpressionVisitor. Even if every QML object has a "parent" property of type QQuickItem, the user most of the time wants to refer to the enclosing QML component when he/she types "parent". If there is no enclosing QML component (the current component is a top-level one or something else happened), then ExpressionVisitor falls back to the old behavior and returns a QQuickItem instance.
> 
> I would like to be able to activate this special handling of "parent" only for QML files, because Javascript files may use "parent" for something else. Is it possible, given a DUContext, to find its language? (or is there a way for the QML/JS plugin to store in the DUContext that the file is a Javascript one or a QML one?)
> 
> 
> Diffs
> -----
> 
>   codecompletion/tests/qmlcompletiontest.cpp 1b5cdee 
>   duchain/expressionvisitor.cpp 6545997 
>   tests/files/test.qml 2d3dc7d 
> 
> Diff: https://git.reviewboard.kde.org/r/118700/diff/
> 
> 
> Testing
> -------
> 
> A new unit test has been added. "parent" is used to refer to the enclosing component of a sub-component, and uses are correctly built. The rest of the unit tests pass. Manual testing shows that the highlighting of "parent" and the code-completion for "parent." is as expected.
> 
> 
> Thanks,
> 
> Denis Steckelmacher
> 
>

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