Qt5/Mac header finding in KDevelop5 (clang parser??)

[Milian Wolff]

On Mittwoch, 22. Juni 2016 17:36:49 CEST René J.V. Bertin wrote:
> On Wednesday June 22 2016 16:42:11 Milian Wolff wrote:
> > We use libclang, we don't do anything ourselves. If it works in clang,
> > then we maybe just miss a setting or commang line parameter to enable the
> > feature.

> Do you also get the header file paths from libclang?

We feed libclang with the include paths. All the rest is handled by libclang. 
What do you mean by "header file path"? Resolving #include? Yes, that is 
handled by libclang of course (why else would we feed it the include paths 
after all?).

> From what I can tell
> the parser indeed gets the definitions from those files but the editor
> doesn't know which file to open.

Ah, so you are talking about context browsing, and not about actual parse 
errors. Please, pretty please - be more specific (not necessarily more 
verbose), when writing your mails...

> IOW, changing #import into #include
> doesn't change necessarily change anything w.r.t. code colouring, and you
> can jump to a type's definition in that headerfile via the code browser
> with both directives.

OK, see above. That was completely unclear to me so far.

> The change only means you can open the header via a
> right-click on the include directive. Changing say a Qt header include to
> "#import <QtFoo> has the opposite effect, everything still works except
> opening the headerfile from the include directive.

Have a look at clangsupport.cpp, cf. it's importedContextForPosition. That 
relies on the DUChain import structure to find lines that correspond to an 
#include. If you say the code browsing and syntax highlighting works, then the 
import structure in the DUChain should also be correct. Potentially what's 
broken is the check for CXCursor_InclusionDirective in clanghelpers.cpp' 
visitCursor callback. Can you inspect that?

> I cannot check right now but I see no reason why it wouldn't be the same on
> Linux. It's easy enough to verify for anyone.

Lack of time is one reason.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160623/5ff7378f/attachment-0001.sig>