[analyze] [CTU] Add support for pch paramteres of clang-extdef-mapping
This patch is about supporting https://reviews.llvm.org/D128704 from Clang.
When doing CTU analysis setup we parse the .cpp to get an .ast and then we run clang-extdef-mapping on the .cpp file later. This is sub-optimal since we have to re-parse the file again.
With this patch we can now run clang-extdef-mapping directly on the .ast file. That saves some time.
Fixes https://github.com/Ericsson/codechecker/issues/3703
The overall CSA runtime (with the default profile) improved roughly with 1-2 % in case of C++, and with 0-1% in case of C.

Ping
Technically it looks good to me, though, it's not clear why relative/absolute paths matter. Maybe it would be worth for a comment about its reasons.
Thanks for the review! Relative/absolute paths matter because the "on-demand" and the "pch" based CTU uses the paths differently. This is documented in ctu_manager.py at the function func_map_list_src_to_ast:
""" Turns textual function map list with source files into a
mapping from mangled names to mapped paths, which can be absolute paths to
the original source files if ctu_on_demand is True, or relative path
segments to AST-dump files that reside in CTU-DIR directory otherwise. """
Ping
Ping @Szelethus
This absolutely cannot go in without a proper PR description and commit message. Please make the review, and the subsequent archeology easier.
Does this have a corresponding LLVM commit and/or phabricator revision? Is there an issue or something for this? Why do we need this? Whats to gain?
This patch is about supporting https://reviews.llvm.org/D128704 from Clang.
When doing CTU analysis setup we parse the .cpp to get an .ast and then we run clang-extdef-mapping on the .cpp file later. This is sub-optimal since we have to re-parse the file again.
With this patch we can now run clang-extdef-mapping directly on the .ast file. That saves some time.
BTW, the commit message refers to an issue that describes the meaning of this PR: Fixes https://github.com/Ericsson/codechecker/issues/3703