Lots of features built on top of ASTs require getting back to the path
of the TU and they used lossy conversion from file ids using sourcemanager.
This patch preserves the file path passed by the caller inside ParsedAST for
later use.
Details
- Reviewers
ilya-biryukov - Commits
- rG3b8fb471cbbd: [clangd][NFCI] Store TUPath inside ParsedAST
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I want to understand the trade-offs a bit better.
- what are the actual differences between the file paths passed to TU and the canonical path in source manager?
- what issues does having these differences result in?
Having some tests that illustrate the difference in a real-world setting would be helpful too.
We would still have to go through source manager to produce results for anything but the main file.
This means that after this change we effectively add complexity the path handling by adding an extra code path for the main file.
Moreover, it's the most common path we return, so we could make any problems with the paths from the source manager appear less frequently and, hence, harder to notice and diagnose.
LGTM and a few nits. Could you please add a summary of our offline discussion here?
clang-tools-extra/clangd/ParsedAST.cpp | ||
---|---|---|
763 | NIT: use Path. | |
clang-tools-extra/clangd/ParsedAST.h | ||
112 | NIT: could you add a comment how this is used, e.g. this path is used as a hint when canonicalize the path. |
as discussed offline, this patch stores the filepath provided by the client (e.g. vscode) which is usually the filepath seen by the user, inside the ParsedAST and later on uses that when a hint is needed for translating filepaths coming from sourcemanager into uris.
this gets rid of the extra canonicalization needed for the main file path (which could fail when we don't have a current working directory set, i.e. in tests) and also does always the "right" thing as all the files should be relative to the workspace of the main file path seen by the user, not the version clangd derives somehow.
clang-tools-extra/clangd/ParsedAST.cpp | ||
---|---|---|
763 | this is a private constructor and public interface also receives a stringref and none of the production callers actually have an extra copy of the filename lying around. so i'd rather keep it as is. | |
clang-tools-extra/clangd/ParsedAST.h | ||
112 | i'd rather not complicate the wording here. i think mentioning the fact that this is the filepath as provided by the caller is enough. being used as a hint for canonicalization of other paths is something specific to the application (and is a result of being the path provided by caller anyway.) |
NIT: could you add a comment how this is used, e.g. this path is used as a hint when canonicalize the path.
Also useful to document that we expect this to be absolute/"canonical".