1693350 - Clangd symbol references take me to symlinked headers, not canonical locations

Status: NEW

(Developer Infrastructure :: Developer Environment Integration, enhancement, P3)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

When using VSCode's + mozilla's clangd integration, I hit F12 to go to the definition (or Shift-F12 to go to declaration) and I find it opens a new editor pointing to the symlink'd include of a header, rather than the original.

i.e., I in ScriptPreloader.cpp I hit F12 with mScripts highlighted, and the editor for obj-debug-browser-x86_64-pc-linux-gnu/dist/include/mozilla/ScriptPreloader.h opens rather than the expected js/xpconnect/loader/ScriptPreloader.h. The former is a symlink to the latter.

This is mostly a papercut.

MOZCONFIG:

ac_add_options --enable-js-shell

ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-warnings-as-errors
ac_add_options --enable-ccache=ccache
ac_add_options --enable-tests
ac_add_options --enable-clang-plugin

# Dump opt builds into another dir.
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-debug-browser-@CONFIG_GUESS@

# For browser builds, because I do them infrequently, enable autoclobber
mk_add_options AUTOCLOBBER=1

Clangd Plugin configured with ./mach ide vscode

Comment 1

[Botond Ballo [:botond]]

I think this is expected behaviour, because the include path in the compile commands is -I<objdir>/dist/include, so the #include "mozilla/ScriptPreloader.h" is resolved to the path <objdir>/dist/include/mozilla/ScriptPreloader.h.

Clangd should work fine with <objdir>/dist/include/mozilla/ScriptPreloader.h open in an editor, i.e. symbols should be resolved and code navigation should work, because we pass the --compile-commands-dir command-line argument to clangd, which ensures it uses our compile_commands.json even for files which are outside the workspace.

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

This is mostly a papercut because VSCode will let you have both open at once, which was hugely confusing for a while. If I open the header manually, I will of course open the 'canonical' version, so then having symbol nav take me to another editor with the same file was at least surprising.

Comment 3

[Botond Ballo [:botond]]

Ok, I see. Yeah, I've experienced this as well and I agree it's confusing.

Clangd doesn't currently have an option to resolve symlinks while indexing (such that the path in the result of a go-to-definition request would already be the target of the symlink), but there is an open issue about this.

Alternatively, perhaps the issue could be solved at the editor level (that is, even though the path in the result of the go-to-definition request is <objdir>/dist/include/mozilla/ScriptPreloader.h, somehow get VSCode to resolve the symlink and open the file at the target path instead)? Not sure about this.

Comment 4

[Steve Fink [:sfink] [:s:]]

The other way this shows up is if I switch between objdirs, I could end up with more than 2 copies of the same file. I don't use F12/Shift-F12 much, so my usual way of getting this to happen is Ctrl-clicking on a filename in a compile error or warning in the terminal pane. The suggested clangd indexing fix would not solve my version of the problem, but the editor-level solution would.

Still, I agree that it's just a papercut.