Review Request 119208: Use DUContext::Class instead of DUContext::Namespace when declaring namespace contexts

[Denis Steckelmacher]

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

(Updated July 10, 2014, 12:29 p.m.)


Status
------

This change has been marked as submitted.


Review request for KDevelop.


Repository: kdev-qmljs


Description
-------

KDevPlatform sometimes special-cases contexts having the Namespace type. This was not a problem until I discovered that this QML snippet does not work:

    :::javascript
    import "myfile.js" as MyFile

    Item {
        onTest: console.log(MyFile.myVariable)
    }

In order to better see which contexts are used, here is the same snippet in a C++-like language:

    :::cpp
    namespace MyFile {
        alias myVariable = "myVariable in myfile.js";
    }
    
    class __ : public Item {
        void onTest() {
            console.log(MyFile::myVariable);
        }
    };

The line starting with "onTest" calls findDeclarations(myVariable) on MyFile, that is a namespace (and has a namespace context). myVariable is a local declaration of MyFile, but is not returned by findDeclarations because an if statement skips findLocalDeclarations for Namespace contexts. A comment in language/duchain/ducontext.cpp says that declarations in namespace contexts are resolved in the top-context, but this cannot happen in my case because I set the DontSearchInParent flag when looking for object members.

This patch work-arounds this issue by giving a Class type to the internal contexts of namespace declarations. This way, KDevPlatform does not special-case the contexts and works as expected.


Diffs
-----

  duchain/declarationbuilder.cpp 8927633 

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


Testing
-------

The whole testsuite passes. The feature shown above (importing Javascript files) is not added by this patch, but is made to work with this patch applied.


Thanks,

Denis Steckelmacher

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