A header spelling in a source file could potentially mean multiple
sources, especially in projects with multiple include search paths. We
try to eliminate this ambiguity by using the resolved path in the
diagnostics. This should improve the life of both the developers and the
tooling.
Details
Details
- Reviewers
sammccall
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
It is the absolute path of the header. e.g:
module TestTU does not depend on a module exporting '/work/llvm/clang-tools-extra/clangd/AST.h'
rather than
module TestTU does not depend on a module exporting 'AST.h'
Comment Actions
We discussed this a bit offline, and IIUC the plan is not to push this through at least for now. Notes:
- path to a file is more accurate/informative than spelling, since it really is the file rather than the name that is restricted
- however in practice the spelling probably isn't ambiguous and is more readable, so this is probably a regression overall for display
- our motivation here is to be able to unambiguously extract the path programmatically.
- Adding a struct { string; FileEntry*; } as a diagnostic argument kind is another (somewhat intrusive) way out.
- The (private) codebase we're experimenting on expresses most #includes relative to a single root, so we can probably just live without this at least for a while
- If we do this getName() is probably indeed better than tryGetRealPathName, resolving symlinks may have some bad effects
I'd be tempted to leave the slashes in the globs for readability