Parsing of *.inl files

[Mathias Kraus]

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