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

[Zixu Wang via Phabricator via cfe-commits]

zixuw created this revision.
zixuw added reviewers: ributzka, dang, cishida.
Herald added a project: All.
zixuw requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Proof-of-concept patch. Needs more work.
Transform input headers to relative (angle) includes.
`getRelativeIncludeName` walks `HeaderSearchOptions::UserEntries` to try
to find a relative include stem. Problems:

- do we want the exact logic of `HeaderSearch::suggestPathToFileForDiagnostics`?
- in `ExtractAPIAction::PrepareToExecuteAction` where the includes are transformed, we don't have a pre-processor yet, so we don't have access to a lot of useful information like `HeaderSearch`, headermaps, DirectoryLookup etc.
- we might not always want to transform an absolute path because the resulting relative include name might get remapped in a headermap, for example in test `known_files_only_hmap.c`. But how does it work with modules where we need relative includes? Is the setup in `known_files_only_hmap` even valid?
- reverse lookup in headermap when deciding if the symbol is coming from a knwon file: I think my current implementation is correct and necessary to solve the headermap problem, but might have problems due to the above point: an unknown file might be mapped to the transformed relative name of a known input.

I think the key problem is that, by passing in an input
`/absolute/path/header.h`, do we mean to process the actual content of
that particular header, or do we mean to use it just as a "lable" and
the thing we really want to process is whatever this lable points to
with the given search paths and headermaps?
In the example of frameworks, I think the latter is true: we want to
use DSTROOT to pass in the headers because DSTROOT has a defined
framework layout so that we can transform the paths to framework-style
relative includes by matching the layout pattern `*.framework/Header/`
and rely on headermaps/VFS/module/search paths to find the intended
headers.
In that sense, the `known_files_only_hmap` test is a really strange
setup with ambiguious intention and context.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123831

Files:
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D123831.423004.patch
Type: text/x-patch
Size: 7480 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20220415/12f785b7/attachment.bin>