"make private" section has weird prefixes before header names

[nikic]

Running include-guardian 0.0.8 on LLVM, the "make private" section (and a few others) contains entries like these:

      - file: '"clang/lib/StaticAnalyzer/Checkers/clang/StaticAnalyzer/Core/BugReporter/clang/StaticAnalyzer/Core/clang/Analysis/clang/Analysis/clang/Analysis/clang/AST/clang/AST/Attrs.inc"'
        reference count: 1
        saving: 1.63 # (%)

The actual name of the header is clang/AST/Attrs.inc, but there are a bunch of prefixes, possibly from places where it is included?

I've uploaded the compile_commands.json file here, in case it is useful: https://gist.github.com/nikic/c1bee11144aafa4e872525dfca3e04e2

---

Also, thanks a lot for creating this tool, it's awesome!

[IncludeGuardian]

Thanks for reporting. There's some logic inside IncludeGuardian to try and come up with a reasonable guess to what relative path we should report for an include and it seems to get tripped up a little in some situations.

For example if we have a library gecko

src/include/gecko/a.hpp
src/include/gecko/b.hpp

where users of this library add the include directory src/include when compiling to access gecko headers via #include "gecko/a.hpp".

If a.hpp has the include directive #include "b.hpp", we probably want to report this file as "gecko/b.hpp" within the report and not "b.hpp".

I think in this case if a.hpp used #include "gecko/b.hpp" we might end up in the situation of reporting gecko/gecko/b.hpp as the canonical file path in the report.

I'm in the process of open sourcing IncludeGuardian and I can take a look (or anyone can) at this in a week or so.

[IncludeGuardian]

@nikic Sorry for the delay, the tool has been open sourced now at https://github.com/elliotgoodrich/includeguardian :D

This is the code that builds up the "nice" path https://github.com/elliotgoodrich/includeguardian/blob/7f7eb80ab25ff785a9dd1a6a47e5b3caa987df0a/src/build_graph.cpp#L627-L658. It assumes that angled include directives (#include <foo.h>) are a "nice" name for an included file and a non-angled include (`#include "foo.h") should be relative to the last angled include (if we have one). I'm unsure right now about the best way to go about fixing this in the tool (right now I'm focused on getting incremental builds working on pull requests when projects are using ninja https://github.com/elliotgoodrich/trimja).

By the way, I really like your site (https://llvm-compile-time-tracker.com/) to track LLVM compilation times. If you ever wanted to integrate includeguardian and needed some help (or had any questions on includeguardian). Don't hesitate to reach out to me!