[Differential] [Updated] D583: Fix DUChainUtils::getInheriters.

gsmolarczyk (Gustaw Smolarczyk) noreply at phabricator.kde.org
Tue Nov 24 20:37:32 UTC 2015


gsmolarczyk marked 2 inline comments as done.
gsmolarczyk added a comment.

In https://phabricator.kde.org/D583#11138, @mwolff wrote:

> Just a question: Is the clang builder correct in importing the base for the case you have in your unit test?
>
>   class foo { class inner {}; };
>   
>
> Why is `inner` importing `foo` - does anyone know? If that wouldn't be the case, then this patch here wouldn't be required. So before we accept this patch, I'd appreciate if someone could dig in a bit deeper and clarify whether it isn't a bug in kdev-clang that triggers the issue, instead of a generic DUChain issue here.


I am not sure about the importing stuff. I thought that it visualizes a dependency between types, like type Foo imports Bar because it cannot work without the Bar.
If that is indeed the case, then importing might be a good idea. You cannot lookup the id of the inner class without the outer class. But the basic definition of the inner class should not implicitly depend on the outer class.

Regardless, the code that marks the outer class as an import of the inner class is in language/clang/duchain/builder.cpp:423 in Visitor::createContext method. According to the code, every method and class imports its semantic parent. It might be a good idea for out-of-line method/class definition, but it is done even if semantic parent == lexical parent.


REPOSITORY
  rKDEVPLATFORM KDevPlatform

REVISION DETAIL
  https://phabricator.kde.org/D583

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: gsmolarczyk, KDevelop
Cc: mwolff, kdevelop-devel, arrowdodger


More information about the KDevelop-devel mailing list