This is done so that clangd can propose the correct include path when
a include directory contains a symlink.
Details
- Reviewers
- None
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Support/VirtualFileSystem.cpp | ||
---|---|---|
1165 | FYI: This is the first time I worked with this codebase. Is there a better way to do this? |
Sorry, I removed the reviewers again, because this might still need some work e2e anymore. I will update this once I resolved that.
I'm out on vacation the next two weeks, happy to look once back, otherwise @kadircet would be the person to review this on the clangd side.
A couple of general notes:
- people use symlinks in different ways, to give files multiple names, the idea that we can tell which path is "better" is mostly false. Improving one case probably makes another worse.
- at first glance, this seems to change the behavior that FileEntry::getName() starts with the include path as spelled in -I etc. This seems like a significant change that is likely to impact a lot of places that may be under-tested, like spellings of filenames in diagnostics.
clang/lib/Lex/InitHeaderSearch.cpp | ||
---|---|---|
179 | Non-equality doesn't mean it's a symlink, some parent could be, or it could simply have been a relative path (can those get here?) |
Thanks a lot for your notes! Unfortunately I noticed that while the test that I created passed, my actual issue [0] still persists and I sent out the change too early. It seems you are right and the symlink handling is in fact more nuanced.
Enjoy your vacation! I will go on vacation soon as well, so no hurries with the review.
[0] https://github.com/hedronvision/bazel-compile-commands-extractor/issues/136
Non-equality doesn't mean it's a symlink, some parent could be, or it could simply have been a relative path (can those get here?)