Review Request 119178: Set every declaration as always direct

Sven Brauch svenbrauch at googlemail.com
Tue Jul 8 14:08:00 UTC 2014



> On July 8, 2014, 1:52 p.m., Milian Wolff wrote:
> > this sounds wrong. Where is the lookup for "dont_use_me" done, that should be adapted to only look in the context of array{}, which should be of Class type and not propagate up into other contexts.
> 
> Denis Steckelmacher wrote:
>     This is already the case. When I put debug statements in DeclarationBuilder and even UseBuilder, everything is correct. When I ask ExpressionVisitor to find the declaration corresponding to "array.dont_use_me", the automatic declaration of "array.dont_use_me" on line 3 is returned. In fact, every call to newUse() is correct :
>     
>     * newUse(line 3 col 1 to 5, var array)
>     * newUse(line 3 col 7 to 17, automatic declaration of dont_use_me, the declaration is on line 3 col 7 to 17)
>     
>     "var dont_use_me" is never passed to any newUse call, so another mechanism is responsible for changing the right "dont_use_me" to the one I don't want, after newUse has been called. By forcing the declarations to be direct, I think that I force KDevelop to keep my declarations and not to try to re-resolve using their names.

I think Denis is right. This flag was introduced for Python back then, with a similar problem. The special case which makes it necessary is that you add members to a class from outside its context. I'm not sure why the name resolution causes this particular issue though.


- Sven


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


On July 8, 2014, 1:19 p.m., Denis Steckelmacher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119178/
> -----------------------------------------------------------
> 
> (Updated July 8, 2014, 1:19 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-qmljs
> 
> 
> Description
> -------
> 
> This patch calls "setAlwaysForceDirect" on every declaration created by the QMLJS plugin. I don't know what are all the implications, but it solves a nasty bug:
> 
> var dont_use_me;
> var array = {};
> array.dont_use_me = "fail";
> 
> In this snippet, without this patch, "array.dont_use_me" is considered to be an use of "var dont_use_me". I've verified that UseBuilder does not create an use for "var dont_use_me" on line 3. It still creates an use for "array.dont_use_me" that is automatically declared on line 3, though.
> 
> I think that line 3 is still considered to be an use of line 1 because the two incrimined declarations (the variable and the object member) have the same name. Moreover, "array" has an internal context that has no name, so the scope of the two declarations is the same. Using only their name, there is no way to differentiate them, hence the unwanted use. By forcing every declaration to be direct, this problem disappears.
> 
> I would like some advice here because the fact that a declaration is direct or not seems to have deep implications in KDevelop. Is it correct to have every declaration direct? Why is this not the case by default?
> 
> 
> Diffs
> -----
> 
>   duchain/declarationbuilder.h 1ab77a1 
>   duchain/declarationbuilder.cpp 2ec2f49 
>   tests/files/arrays.js e9a8efa 
> 
> Diff: https://git.reviewboard.kde.org/r/119178/diff/
> 
> 
> Testing
> -------
> 
> The whole testsuite still passes and a new unit test is added (it looks like the example given above). The unit test fails without this patch and passes when this patch is applied. The testsuite is not slowed down nor sped up by this patch.
> 
> 
> Thanks,
> 
> Denis Steckelmacher
> 
>

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


More information about the KDevelop-devel mailing list