Clangd can't jump to the right position

[xzhangxian1008]

Please describe the problem. For hints on what information is helpful, see: https://clangd.llvm.org/troubleshooting.html

When I want to go the definition, clangd will often bring me to a strang position.

I can ensure that the clangd could find header files and compile_commands.json is ok.

I find that if I open the vscode with abc.cpp file as the first file to be parsed. When I want to go to definition, the actual position is aaa.h:47, and clangd will bring me to abc.cpp:47. In a word, the line number is right but it will always bring me to the first open file.

https://github.com/clangd/vscode-clangd/assets/15918072/b5ab4c80-7a11-4d24-875d-e8b72df5e282

Log: log.txt

If you can, provide a minimal chunk of code that shows the problem (either inline, or attach it if larger).

Logs Please attach the clangd log from the "Output" window if you can. If possible, run with --log=verbose - note that the logs will include the contents of open files!

System information Clangd version 15.0.7(https://github.com/llvm/llvm-project 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a): clangd plugin on VSCode version: v0.1.24 Operating system: Rocky Linux release 9.2 (Blue Onyx)

[HighCommander4]

In my experience, this usually happens when the index is out of date, for example when you have pulled the code from upstream while clangd is running. Restating clangd to trigger reindexing of updated files usually helps.

[xzhangxian1008]

In my experience, this usually happens when the index is out of date, for example when you have pulled the code from upstream while clangd is running. Restating clangd to trigger reindexing of updated files usually helps.

Thanks

I delete the clang's cache in my workspace, regenerate the compile_command.json with the latest codes and restart the clangd. However, the problem still exists.

[xzhangxian1008]

In my experience, this usually happens when the index is out of date, for example when you have pulled the code from upstream while clangd is running. Restating clangd to trigger reindexing of updated files usually helps.

I find that if I open the vscode with abc.cpp file as the first file to be parsed. When I want to go to definition, the actual position is aaa.h:47, and clangd will bring me to abc.cpp:47. In a word, the line number is right but it will always bring me to the first open file.

[xzhangxian1008]

In my experience, this usually happens when the index is out of date, for example when you have pulled the code from upstream while clangd is running. Restating clangd to trigger reindexing of updated files usually helps.

After I fallback to clangd 13.0.0, behaviour of clangd begins to be correct.

[HighCommander4]

Log: log.txt

What this log is showing is that go-to-definition is invoked in DecimalComparison.h line 99, and the target is Block.cpp line 183.

Does this match the behaviour you observe visually in the editor? Which part is unexpected?

[xzhangxian1008]

Yes, this match the behaviour I observed, but Block.cpp:183 is not the correct position.

[HighCommander4]

Which file and line is the expected result?

[xzhangxian1008]

Which file and line is the expected result?

DecimalComparison.h:204 is the expected result.(may be line number is not 204, as the codes have little changed in my current workspace)

[HighCommander4]

Is there something in Block.cpp that clangd might confuse for the definition you're looking for, like a function with the same name, or a redeclaration of the same function?

[xzhangxian1008]

Is there something in Block.cpp that clangd might confuse for the definition you're looking for, like a function with the same name, or a redeclaration of the same function?

No, and no matter what function I want to look for, it will always jump to Block.cpp.

[HighCommander4]

Interesting. Taking a closer look at the logs, the following looks pretty suspicious:

I[10:50:27.125] ASTWorker building file /DATA/disk3/xzx/tiflash/dbms/src/Core/DecimalComparison.h version 1 with command inferred from /DATA/disk3/xzx/tiflash/dbms/src/Core/Block.cpp [/DATA/disk3/xzx/tiflash/build] /DATA/disk3/xzx/llvm-15.0.0/bin/clang++ [...] -- /DATA/disk3/xzx/tiflash/dbms/src/Core/DecimalComparison.h V[10:50:27.127] Driver produced command: cc1 [...] -x c++ /DATA/disk3/xzx/tiflash/dbms/src/Core/Block.cpp

Why does the "driver producer command" refer to Block.cpp, when the file being opened in DecimalComparison.h? That's not what I usually see in the logs in the case of a command inferred for a header -- I usually see the "driver produced command" refer to the header file.

[HighCommander4]

Here is something interesting in the transferred compile command:

/DATA/disk3/xzx/llvm-15.0.0/bin/clang++ [...] -c /DATA/disk3/xzx/tiflash/dbms/src/Core/Block.cpp -x c++-header -std=gnu++20 -ferror-limit=0 -resource-dir=/DATA/disk3/xzx/llvm-15.0.0/lib/clang/15.0.7 -- /DATA/disk3/xzx/tiflash/dbms/src/Core/DecimalComparison.h

The command references two source files, Block.cpp before the --, and DecimalComparison.h after.

@xzhangxian1008 could you share the original entry for Block.cpp from your compile_commands.json please?

[xzhangxian1008]

Block.cpp

I believe this is unrelated to compile_commands.json. Because my clangd13.0.0 could jump to the correct position while clangd15.0.7 couldn't with the same compile_commands.json

{
  "directory": "/DATA/disk3/xzx/tiflash/build/dbms",
  "command": "/DATA/disk3/xzx/env-tiflash/sysroot/bin/clang++ -DAWS_SDK_VERSION_MAJOR=1 -DAWS_SDK_VERSION_MINOR=10 -DAWS_SDK_VERSION_PATCH=36 -DBOOST_BIND_GLOBAL_PLACEHOLDERS -DBOOST_NO_CXX98_FUNCTION_BASE -DBOOST_SYSTEM_NO_DEPRECATED -DCARES_STATICLIB -DDBMS_PUBLIC_GTEST -DFIU_ENABLE -DLZ4_DISABLE_DEPRECATE_WARNINGS=1 -DLZ4_FAST_DEC_LOOP=1 -DMULTIPLE_CONTEXT_GTEST -DPOCO_STATIC -DPOCO_UNBUNDLED_ZLIB -DSTACK_LINE_READER_BUFFER_SIZE=1024 -DTIFLASH_COMPILER_VPCLMULQDQ_SUPPORT=1 -DTIFLASH_ENABLE_AVX512_SUPPORT=1 -DTIFLASH_ENABLE_AVX_SUPPORT=1 -DTIFLASH_SOURCE_PREFIX=\\\"/DATA/disk3/xzx/tiflash\\\" -I/DATA/disk3/xzx/tiflash/contrib/libsparsehash -I/DATA/disk3/xzx/tiflash/contrib/libdivide -I/DATA/disk3/xzx/tiflash/dbms/src -I/DATA/disk3/xzx/tiflash/contrib/tiflash-proxy/raftstore-proxy/ffi/src -I/DATA/disk3/xzx/tiflash/contrib/GmSSL/include -I/DATA/disk3/xzx/tiflash/build/dbms/src -I/DATA/disk3/xzx/tiflash/contrib/libbtrie/include -I/DATA/disk3/xzx/tiflash/contrib/abseil-cpp -I/DATA/disk3/xzx/tiflash/build/contrib/etcd -I/DATA/disk3/xzx/tiflash/build/contrib/etcd/etcd -I/DATA/disk3/xzx/tiflash/contrib/grpc/include -I/DATA/disk3/xzx/tiflash/contrib/double-conversion -I/DATA/disk3/xzx/tiflash/contrib/boost -I/DATA/disk3/xzx/tiflash/contrib/xxHash -I/DATA/disk3/xzx/tiflash/contrib/libpcg-random/include -I/DATA/disk3/xzx/tiflash/contrib/libcityhash/include -I/DATA/disk3/xzx/tiflash/libs/libcommon/include -I/DATA/disk3/xzx/tiflash/build/libs/libcommon/include -I/DATA/disk3/xzx/tiflash/libs/libpocoext/include -I/DATA/disk3/xzx/tiflash/contrib/poco/Data/include -I/DATA/disk3/xzx/tiflash/contrib/poco/Foundation/include -I/DATA/disk3/xzx/tiflash/contrib/zlib-ng -I/DATA/disk3/xzx/tiflash/build/contrib/zlib-ng -I/DATA/disk3/xzx/tiflash/contrib/poco/Util/include -I/DATA/disk3/xzx/tiflash/contrib/poco/XML/include -I/DATA/disk3/xzx/tiflash/contrib/poco/JSON/include -I/DATA/disk3/xzx/tiflash/contrib/poco/Net/include -I/DATA/disk3/xzx/tiflash/contrib/cctz/include -I/DATA/disk3/xzx/tiflash/contrib/jemalloc/include -I/DATA/disk3/xzx/tiflash/contrib/jemalloc-cmake/include -I/DATA/disk3/xzx/tiflash/contrib/cpu_features/include -I/DATA/disk3/xzx/tiflash/contrib/libcpuid/include -I/DATA/disk3/xzx/tiflash/contrib/lz4/lib -I/DATA/disk3/xzx/tiflash/contrib/zstd/lib -I/DATA/disk3/xzx/tiflash/contrib/client-c/third_party/libfiu/libfiu -I/DATA/disk3/xzx/tiflash/contrib/prometheus-cpp/core/include -I/DATA/disk3/xzx/tiflash/build/contrib/prometheus-cpp-cmake/core/include -I/DATA/disk3/xzx/tiflash/contrib/prometheus-cpp/push/include -I/DATA/disk3/xzx/tiflash/build/contrib/prometheus-cpp-cmake/push/include -I/DATA/disk3/xzx/tiflash/contrib/prometheus-cpp/pull/include -I/DATA/disk3/xzx/tiflash/build/contrib/prometheus-cpp-cmake/pull/include -I/DATA/disk3/xzx/tiflash/contrib/cpptoml -I/DATA/disk3/xzx/tiflash/contrib/magic_enum/include -I/DATA/disk3/xzx/tiflash/contrib/poco/NetSSL_OpenSSL/include -I/DATA/disk3/xzx/tiflash/contrib/poco/Crypto/include -I/DATA/disk3/xzx/tiflash/contrib/xxHash/cmake_unofficial/.. -I/DATA/disk3/xzx/tiflash/build/contrib/kvproto/cpp -I/DATA/disk3/xzx/tiflash/build/contrib/kvproto/cpp/kvproto -I/DATA/disk3/xzx/tiflash/contrib/client-c/include -I/DATA/disk3/xzx/tiflash/build/contrib/grpc/third_party/cares/cares -I/DATA/disk3/xzx/tiflash/contrib/grpc/third_party/cares/cares -I/DATA/disk3/xzx/tiflash/build/contrib/tipb/cpp -isystem /DATA/disk3/xzx/tiflash/contrib/boringssl/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws/src/aws-cpp-sdk-core/include -isystem /DATA/disk3/xzx/tiflash/build/contrib/aws-cmake/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws/generated/src/aws-cpp-sdk-s3/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws/generated/src/aws-cpp-sdk-sts/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws-c-auth/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws-c-common/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws-c-io/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws-crt-cpp/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws-c-mqtt/include -isystem /DATA/disk3/xzx/tiflash/contrib/aws-c-sdkutils/include -isystem /DATA/disk3/xzx/tiflash/contrib/protobuf/src -isystem /DATA/disk3/xzx/tiflash/libs/libprocess_metrics/include -isystem /DATA/disk3/xzx/tiflash/contrib/fmtlib-cmake/../fmtlib/include -isystem /DATA/disk3/xzx/tiflash/libs/libsymbolization/include -isystem /DATA/disk3/xzx/tiflash/contrib/re2 -isystem /DATA/disk3/xzx/tiflash/build/contrib/re2-cmake   -pipe -mssse3 -msse4.1 -msse4.2 -mpclmul -mpopcnt  -fno-omit-frame-pointer  -Wall -Wno-unused-command-line-argument  -Wnon-virtual-dtor  -stdlib=libc++ -Wextra -Werror -g -g3 -ggdb3 -O0 -fverbose-asm -fno-inline  -D_LIBCPP_DEBUG=0 -std=gnu++20 -fPIC -DDUMMY_BACKTRACE -o CMakeFiles/dbms.dir/src/Core/Block.cpp.o -c /DATA/disk3/xzx/tiflash/dbms/src/Core/Block.cpp",
  "file": "/DATA/disk3/xzx/tiflash/dbms/src/Core/Block.cpp",
  "output": "dbms/CMakeFiles/dbms.dir/src/Core/Block.cpp.o"
},

[HighCommander4]

Could you show a log (similar to the one in the first comment) from clangd 13.0?

[xzhangxian1008]

Could you show a log (similar to the one in the first comment) from clangd 13.0?

here

clangd13.txt

[HighCommander4]

Ok, so with clang 13, the transferred compile command is:

/DATA/disk3/xzx/env-tiflash/sysroot/bin/clang++ [...] -c -x c++-header -std=gnu++20 -ferror-limit=0 -resource-dir=/DATA/disk3/xzx/env-tiflash/sysroot/lib/clang/13.0.0 -- /DATA/disk3/xzx/tiflash/dbms/src/Core/DecimalComparison.h

Note that the path of Block.cpp after -c is no longer present.

This makes me suspect that something changed in transferCompileCommand() between clangd 13 and clangd 15.

What's still not clear to me is, what is it about this compile command that causes this strange outcome in clangd 15? Clearly it doesn't happen all the time, otherwise we would have received previous reports about it.

[xzhangxian1008]

compile command you mean cmake command or clang command? Is there more information you need?

[HighCommander4]

compile command you mean cmake command or clang command?

I mean the clang command in the compile_commands.json entry. I'm not saying there's anything wrong with it, I'm just speculating that there is something different about it which trips a bug in clangd when it processes the command (but I don't know what yet).

Is there more information you need?

I think a good next step is to try to reproduce the unexpected transferCompileCommand() result seen in the log. I will try that when I have time.

I would however be curious to know if this happens for you with a different project, or on a different machine.

[xzhangxian1008]

I would however be curious to know if this happens for you with a different project, or on a different machine.

I will try it.

[xzhangxian1008]

I would however be curious to know if this happens for you with a different project, or on a different machine.

I tried the same project on another machine, and the project ClickHouse on the same machine, the bug happens again.

[xzhangxian1008]

@HighCommander4 hi~ can you reproduce this bug? I can provide any information if you need.

[HighCommander4]

Sorry for not following up on this sooner.

I think a good next step is to try to reproduce the unexpected transferCompileCommand() result seen in the log

I've tried just now to see if I can reproduce the unexpected transferCompileCommand() behaviour with a compile_commands.json like the one you posted here, but it works as expected for me.

Have you tried with a newer version than clangd 15, such as clangd 18 from https://github.com/clangd/clangd/releases/tag/18.1.3?

If the issue still occurs with clangd 18, a workaround I can think of is to post-process your compile_commands.json with https://github.com/Sarcasm/compdb to add entries for header files (so e.g. after the post-processing, DecimalComparison.h should now have its own entry). This should avoid the transferCompileCommand() codepath in clangd and so whatever issue is happening there shouldn't affect you any more.

[xzhangxian1008]

Sorry for not following up on this sooner.

I think a good next step is to try to reproduce the unexpected transferCompileCommand() result seen in the log

I've tried just now to see if I can reproduce the unexpected transferCompileCommand() behaviour with a compile_commands.json like the one you posted here, but it works as expected for me.

Have you tried with a newer version than clangd 15, such as clangd 18 from https://github.com/clangd/clangd/releases/tag/18.1.3?

If the issue still occurs with clangd 18, a workaround I can think of is to post-process your compile_commands.json with https://github.com/Sarcasm/compdb to add entries for header files (so e.g. after the post-processing, DecimalComparison.h should now have its own entry). This should avoid the transferCompileCommand() codepath in clangd and so whatever issue is happening there shouldn't affect you any more.

Thank you! I find that clangd 18.1.3 not occurs this bug any more. Should I close this issue?

[HighCommander4]

Glad to hear it! Yeah, let's close this.