Parsing of *.inl files

Milian Wolff mail at
Wed May 15 22:28:43 BST 2019

On Freitag, 3. Mai 2019 00:10:26 CEST Mathias Kraus wrote:
> Am Dienstag, 30. April 2019, 14:12:34 CEST schrieb Milian Wolff:
> > Sounds good! If you create a bug, make sure to attach a MWE so we can
> > reproduce the problem easily. If you create a patch, try to come up with
> > an
> > autotest if at all possible.
> Okay, I think I found the problem. I think it's in
> ClangIndex::translationUnitForUrl which is called in ClangParseJob::run.
> Under certain circumstances the wrong translation unit is picked. Instead
> of taking the translation unit of the inl flie, a translation unit from a
> cpp file is picked which happens to include the hpp of the corresponding
> inl.
> e.g.:
> - main.cpp (includes fancy_templated_class.hpp)
> - fancy_templated_class.hpp (includes fancy_templated_class.inl)
> - fancy_templated_class.inl (includes fancy_templated_class.hpp)
> When parsing doesn't work correct, the parse job for
> fancy_templated_class.inl gets the translation unit of main.cpp from
> ClangIndex::translationUnitForUrl. I have to investigate further but it
> seems to be a race between getting a pinned translation unit in
> ClangParseJob::run and pinning the translation unit in
> ClangHelpers::buildDUChain.
> Assuming it's a race condition, would a viable fix ignore other translation
> units if the file is itself a source file?
> Regards, Mathias

There's also `ClangHelpers::sourceExtensions` which we may need to change such 
that it also looks at your system's mimetype configuration to pick up more 
extensions. Similarly that's probably needed for 

Can you try to add inl as a sourceExtension, does that help?


Milian Wolff
mail at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the KDevelop-devel mailing list