[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw added inline comments.


================
Comment at: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp:134
+        if (!SpelledFilename.empty())
+          return SpelledFilename.str();
+
----------------
zixuw wrote:
> zixuw wrote:
> > One problem I can see in this right now is that there might be multiple headermaps that together construct a chain of mapping, for example
> > ```
> > // A.hmap
> > Header.h -> Product/Header.h
> > 
> > // B.hmap
> > Product/Header.h -> /Absolute/path/to/Header.h
> > ```
> > Then this iteration would conclude on using `Product/Header.h` and missed the first mapping (if the command line goes `clang -extract-api -I A.hmap -I B.hmap ...`).
> > 
> > It's also possible that a headermap and a search path together resolve the header. For example:
> > ```
> > //A.hmap
> > Header.h -> Product/Header.h
> > 
> > // Invocation:
> > clang -extract-api /Some/Path/to/Product/Header.h -I A.hmap -I /Some/path/to/
> > ```
> > 
> > I think we need to keep records and iterate backwards on the search paths again to get the full reverse lookup
> Or, iterate once in reverse and find the last match? 🤔 
Another thing just came to me: with multiple headermaps chaining remaps, which is the "correct" way to include a header?
```
// A.hmap
Header.h -> Product/Header.h

// B.hmap
Product/Header.h -> /Absolute/path/to/Header.h
```
In the context of Darwin frameworks, we'd use `<Framework/Header.h>` so we don't want to follow the chain all the way backwards.
But without any context or build system rationales of why multiple headermaps with remap chains are generated in the first place, I'm feeling that we don't nearly have enough information for this if we're only talking about headermap as it is and refraining from adopting heuristics.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123831/new/

https://reviews.llvm.org/D123831