[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Duplicates in response of "textDocument/references" request #2195

Open
procionevolante opened this issue Oct 25, 2024 · 5 comments
Open

Duplicates in response of "textDocument/references" request #2195

procionevolante opened this issue Oct 25, 2024 · 5 comments

Comments

@procionevolante
Copy link

Clangd often reports the same reference to an object multiple times to the text editor.
If the editor doesn't do filtering itself, multiple references will be shown to the user.

I noticed that this issue has been reported already to the LSP I use here and identified as an issue in clangd itself, so I think it is present since then.

Logs

I'm not very practical of writing a Cmake config, so probably my CmakeLists.txt is not so well-structured (anyway it reproduces the problem).

I opened lib.c with gVim and asked for the references to the function libRepro
An extract from the log is here:

[Trace - 15:31:25] Received response 'textDocument/references - (4)' in 3ms.
Result: [
    {
        "range": {
            "end": {
                "character": 12,
                "line": 1
            },
            "start": {
                "character": 4,
                "line": 1
            }
        },
        "uri": "file:///c:/msys64/home/afanti/src/llvm-bug-reproducer/lib.c"
    },
    {
        "range": {
            "end": {
                "character": 12,
                "line": 1
            },
            "start": {
                "character": 4,
                "line": 1
            }
        },
        "uri": "file:///C:/msys64/home/afanti/src/llvm-bug-reproducer/lib.c"
    },

As you can see there is a duplicate, which gets shown on vim.

Full log: clangd.log
My example project: llvm-bug-reproducer.zip

System information

Output of clangd --version:

clangd version 19.1.2 (https://github.com/llvm/llvm-project 7ba7d8e2f7b6445b60679da826210cdde29eaf8b)
Features: windows+grpc
Platform: x86_64-pc-windows-msvc

Downloaded from the github "releases" page.
The same issue is present also in clangd 18.1.3

Editor/LSP plugin:
(g)vim 9.1 with coc-clangd

Operating system:
Windows 10 version 22H2
@HighCommander4
Copy link

The issue is almost certainly related to Windows using a case-insensitive filesystem (#108).

Notice how in the log, one path has a lowercase c in the drive name and the other has uppercase C.

@procionevolante
Copy link
Author

Oh i didn't spot that, makes sense.

I will check on monday if this is the case also on the big project on my work pc

@HighCommander4
Copy link

Taking a closer look at the logs, the source of the inconsistency is likely that the "file" keys in compile_commands.json use C: (causing clangd's background index to contain entries with paths containing C:), but vscode's textDocument/didOpen requests sending paths with c: (causing clangd's in-memory index to contain another set of entries with paths containing c:).

Please see clangd/vscode-clangd#687 (comment) for a suggested workaround.

@procionevolante
Copy link
Author
procionevolante commented Oct 28, 2024 •
edited
Loading

Ok, I confirm the same C:\ vs c:\ thing happens on my project at work.
Now, the workaround of using only the lowercase variant in compile_commands.json seems to work.

The interesting thing is that this project is compiled passing @file arguments to the compiler, to make it read compiler arguments from file.
Now, all these files have the drive letter written in uppercase, but even without changing them it seems that the issue disappears.

EDIT: sometimes the same issue happens anyway, even after changing all "argument files" to the lowercase c:\, and in the logs a duplicate with the uppercase C:\ appears.

@HighCommander4
Copy link

I would expect it's the value of the "file" keys in compile_commands.json in particular that's important, though of course it doesn't hurt to be consistent everywhere including the arguments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@HighCommander4 @procionevolante