Adding option to follow symlinks when resolving symbols #707
Conversation
* Adding remapDefinitionSymlink to follow symlinks on Definitions and Declarations. * Wrapping calls for provideDeclaration, provideDefinition, provideTypeDefinition, provideImplementation with call to remap * Adding config variable to toggle symlink resolution
|
|
||
| return res; | ||
| } else { | ||
| if (definition.uri.scheme != 'file') |
There was a problem hiding this comment.
It would have been preferable to use the vscode filesystem api here, but while it has functionality for checking if a file is a symlink, it doesn't actually have a function to follow it. Gating behind a file uri scheme should avoid situations where you've got some remote filesystem open and we can't actually follow the symlinks
|
It seems that the modification introduced in PR is not working as expected in my environment (listed below), when the follow symlink option is enabled, it resolves the symlink correctly (examined by infomation message) but vscode window still lands inside Version: 1.95.1 (Universal) |
When using clangd in vscode with Bazel — trying to do symbol resolution (Go To Definition, Go To Declaration) will result in a file being opened in the Bazel build intermediate folder. This PR adds a settings flag and middlewares on the symbol resolution functions to follow symlinks back to their actual source file.
This issue has been discussed on the clangd project itself a few years ago. 1 2. From my reading whether or not to follow the symlinks was too deep in the compiler infrastructure itself to change on the LSP server, and that whether or not to follow the symlinks might be situationally dependent.
I attempted to solve the issue using the
--path-mappingsflag but it doesn't seem suitable for this situation.[Hedron's](https://github.com/hedronvision/bazel-compile-commands-extractor generator
compile_commands.jsonalso seemed like an opportunity to generate different compile commands but 3 it doesn't seem like one could get working compile commands that aren't pointing into bazel's sandbox directoryHaving it here behind a feature flag seems like a reasonable middle ground. Folks that need symlink resolution would be able to check the box, and uncheck it if they were getting funky behavior.
I've created a project here to demonstrate the behavior
Symbol Resolution
Without Symlink Following
With Symlink Following