Review Request 124285: Compare declarations using declaration chain and marshaled symbols

[Milian Wolff]

> On July 8, 2015, 8:59 p.m., Milian Wolff wrote:
> > Hm would it help to reuse the information we store in the DUChain maybe? I'm not sure about templates, but for other stuff we intern things there already.
> 
> Maciej Poleski wrote:
>     Can we get information from DUChain for something like `clang::Decl*`?
>     Just out of curiosity, how DUChain handles that? Kind of name mangling?

No, but you can query the Declaration at a given cursor/range in a file. That also has Uses associated to find other places. Then you could use these cursors maybe to map to `clang::Decl*`? This is just guesswork on my side though, I'm not as deep into the topic as you are. Potentially, this does not help you at all.


- Milian


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


On July 7, 2015, 10:11 p.m., Maciej Poleski wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124285/
> -----------------------------------------------------------
> 
> (Updated July 7, 2015, 10:11 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-clang
> 
> 
> Description
> -------
> 
> Compare declarations using declaration chain and marshaled symbols.
> 
> I have serious issue with reflecting declaration entities. Clang provides all required measures for Translation Unit, but we are refactoring whole projects, not single TU.
> 
> When I want to make even the simplest refactoring action (like rename variable) I have to find all declarations of this variable in the whole project (world). It is very simple in TU as Clang provides tools like `getCanonicalDecl()` which returns universal witness of declaration. The problem is that usages of this variable can occur also in other TUs. But in other TU we will have other witness. Clang can't help this. I introduced my own facility to compare declarations "globally". It uses two techniques depending on situation:
> - declaration chains - if we have "local" symbol (local to TU)
> - marshalled symbols (like name mangling) - if we have symbol with external linkage (global)
> 
> The second is rewriting of some language rules. It is very disappointing that such functionality had to be rewritten (it _must_ be somewhere in compiler).
> 
> Currently this feature is employed in rename varaible action. Works (as with older engine). It is going to be used in change signature as well soon. (I was working on change signature when this issue blocked me)
> 
> It seems that I successfully stripped old commits from this new review, but I'm not sure if this fact will be preserved when I begin updates.
> I still didn't succeed pushing old changes to repo...
> 
> 
> Diffs
> -----
> 
>   refactoring/CMakeLists.txt PRE-CREATION 
>   refactoring/debug.h PRE-CREATION 
>   refactoring/declarationcomparator.h PRE-CREATION 
>   refactoring/declarationcomparator.cpp PRE-CREATION 
>   refactoring/declarationsymbol.h PRE-CREATION 
>   refactoring/declarationsymbol.cpp PRE-CREATION 
>   refactoring/documentcache.cpp PRE-CREATION 
>   refactoring/redeclarationchain.h PRE-CREATION 
>   refactoring/redeclarationchain.cpp PRE-CREATION 
>   refactoring/refactoringmanager.cpp PRE-CREATION 
>   refactoring/renamevardeclrefactoring.h PRE-CREATION 
>   refactoring/renamevardeclrefactoring.cpp PRE-CREATION 
>   refactoring/tudecldispatcher.h PRE-CREATION 
>   refactoring/tudecldispatcher.cpp PRE-CREATION 
>   refactoring/utils.h PRE-CREATION 
>   refactoring/utils.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/124285/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Maciej Poleski
> 
>

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