Parsing of *.inl files
mail at milianw.de
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
> - 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
> 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?
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel