Extension has become unresponsive since 1.23.1

[j-marcon]

Environment

• OS and Version: WSL2 Ubuntu 20.04 from Windows 11
• VS Code Version: 1.98.2
• C/C++ Extension Version: 1.23.1

Bug Summary and Steps to Reproduce

Bug Summary: Intellisense has become unusable. When I hover over objects, it loads indefinitely.

Steps to reproduce:

1. Open a C++ file
2. Hover over a word for description
3. "Loads" forever

Expected behavior: I should get the description of the object.

Configuration and Logs

{
  "configurations": [
    {
      "name": "Mac",
      "includePath": [
        "${workspaceFolder}/**",
        "/usr/local/opt/openmpi/**"
      ],
      "compilerPath": "/usr/bin/clang",
      "cppStandard": "c++17",
      "compileCommands": "${workspaceFolder}/compile_commands.json"
    }
  ],
  "version": 4
}


I'm getting a bunch of

Attempting to get defaults from C++ compiler in "compilerPath" property: '/usr/bin/clang'
Compiler query command line: /usr/bin/clang --target=x86_64-unknown-linux-gnu -fstack-protector -fno-omit-frame-pointer -fcolor-diagnostics -g0 -O2 -ffunction-sections -fdata-sections -std=c++17 -stdlib=libstdc++ -frandom-seed=[...] -fPIC -fopenmp -gdwarf-4 -no-canonical-prefixes -fdebug-prefix-map=external/llvm_toolchain_llvm/=__bazel_toolchain_llvm_repo__/ -Wp,-v -fno-blocks -E -dM -x c++ /dev/null

and

clang: �[0;1;31merror: �[0munsupported option '--expt-relaxed-constexpr'�[0m
clang: �[0;1;31merror: �[0munsupported option '--extended-lambda'�[0m

then

LSP: (received) cpptools/hover: [...] (id: 85)
LSP: (invoked) cpptools/hover: [...] (id: 85)
Populating file name cache...
LSP: $/cancelRequest (cpptools/hover, id: 85)
Done populating filename cache. Elapsed time: 8510 ms
Error squiggles will be disabled in: [...]

Other Extensions

No response

Additional context

Reverting to 1.23.0 works. We use bazel to generate compile commands.

[Colengms]

Hi @j-marcon . I don't see any instances of the two unsupported options on the command you provided. Could you provide complete command-lines for each of the compiler queries that fail? Perhaps both the original command line, if possible, and the failed query associated with it in the log?

The extension tries to query the compiler using only the arguments from the command line that are relevant. Sometimes LLVM adds new arguments that we need to account for when composing compiler query command lines. Sometimes those arguments are arg-sequences that we need to know about in order to strip/include their arg values as well. Given a complete command line that it's failing to configure against, it's usually pretty straightforward for us to address the issue.

[j-marcon]

Hi @j-marcon . I don't see any instances of the two unsupported options on the command you provided. Could you provide complete command-lines for each of the compiler queries that fail? Perhaps both the original command line, if possible, and the failed query associated with it in the log?

The extension tries to query the compiler using only the arguments from the command line that are relevant. Sometimes LLVM adds new arguments that we need to account for when composing compiler query command lines. Sometimes those arguments are arg-sequences that we need to know about in order to strip/include their arg values as well. Given a complete command line that it's failing to configure against, it's usually pretty straightforward for us to address the issue.

Hi @Colengms, sorry about that. Here's what one looks like:

Compiler query command line: /usr/bin/clang --target=x86_64-unknown-linux-gnu -fstack-protector -fno-omit-frame-pointer -fcolor-diagnostics -g0 -O2 -ffunction-sections -fdata-sections -std=c++17 -stdlib=libstdc++ -frandom-seed=[...] -fPIC -fopenmp -gdwarf-4 --expt-relaxed-constexpr --extended-lambda -no-canonical-prefixes -fdebug-prefix-map=[...] -Wp,-v -fno-blocks -E -dM -x c++ /dev/null

Let me know if you need any other information.

[Colengms]

Hi @j-marcon . The example command line you provided does not run for me locally. I get:

/usr/bin/clang --target=x86_64-unknown-linux-gnu -fstack-protector -fno-omit-frame-pointer -fcolor-diagnostics -g0 -O2 -ffunction-sections -fdata-sections -std=c++17 -stdlib=libstdc++ -frandom-seed=[...] -fPIC -fopenmp -gdwarf-4 --expt-relaxed-constexpr --extended-lambda -no-canonical-prefixes -fdebug-prefix-map=[...] -Wp,-v -fno-blocks -E -dM -x c++ /dev/null
clang: error: unknown argument: '--expt-relaxed-constexpr'
clang: error: unknown argument: '--extended-lambda'
clang: error: invalid argument '[...]' to -fdebug-prefix-map=

... Which seems to correspond to what the extension is getting. Does this run for you locally without the same errors?

Also, are the ...'s placeholders for other actual values? Can you provide a complete complete command line that works for you directly but is not accepted by the extension? Perhaps something in the "..." is causing arg parsing to fail.

To clarify, could you provide an original command line from your compiler_commands.json (form before it gets converted into a compiler query command line)?

[j-marcon]

@Colengms, actually I don't seem to be getting this error when I run it locally:

clang -cc1 version 10.0.0 based upon LLVM 10.0.0 default target x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
ignoring duplicate directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9
 /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9
 /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward
 /usr/local/include
 /usr/lib/clang/10.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

But also, I don't think /usr/bin/clang is what is used to compile our Bazel C++ code. We seem to use LLVM 14.0.0 instead.

As for ..., I was just using that as a placeholder as I'm not sure I can share the real file names.

[Colengms]

But also, I don't think /usr/bin/clang is what is used to compile our Bazel C++ code. We seem to use LLVM 14.0.0 instead.

Hi, @j-marcon . Do the command lines in your compile_commands.json refer to /usr/bin/clang (which is in the command line you've provided) ?

I see from your base configuration that you have:

"compilerPath": "/usr/bin/clang",

When using a compile_commands.json, if compilerPath is also explicitly set, it will override the compiler specified in your compile_commands.json. Try removing that from your base configuration, or setting it to the same compiler used by your compile_commands.json.

Otherwise, in order to understand why it's not being parsed correctly, I would need to see an example entry from your compile_commands.json (that still reproduces the issue after any modifications to remove filenames). A good approach would be to compose a self-contained repro of the issue in the form of a GitHub repo.

[j-marcon]

Hi @Colengms,

Do the command lines in your compile_commands.json refer to /usr/bin/clang (which is in the command line you've provided) ?

No, they refer to a Python wrapper that we use around clang.

I have tried to unset compilerPath in my c_cpp_properties.json but that didn't make any difference.

It seems this problem is very specific to my setup and repo. I'm not sure I'll be able to repro. Anyway, thanks for your help!

[vbaderks]

@j-marcon I have a similar setup: a large C++ project that is using Bazel as build system. I am still using 1.22.11 as newer versions always seem to scan forever for Intellisense and don't complete. I have enabled full debug logging, but was not able to find useful hints.

[j-marcon]

@j-marcon I have a similar setup: a large C++ project that is using Bazel as build system. I am still using 1.22.11 as newer versions always seem to scan forever for Intellisense and don't complete. I have enabled full debug logging, but was not able to find useful hints.

Thanks @vbaderks, I feel validated! Is your project open? Could you share it with @Colengms ?

[vbaderks]

@j-marcon I am sorry, the project is closed. I saw some tips in this discussion from @Colengms, that I could try. If I have some positive to post, I will let you know.

[github-actions]

Hey @Colengms, this issue might need further attention.

@j-marcon, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[vbaderks]

With v1.26.1 I see sometimes:

cpptools-srv
6/19/2025, 10:55:07 AM
SIGSEGV
a_completion_symbol_manager::save_class_members(a_symbol_with_origin const&, edge::list<a_symbol_with_origin>&)+265
a_completion_symbol_manager::handle_class_struct(a_symbol_with_origin const&, edge::list<a_symbol_with_origin>&)+166
a_completion_symbol_manager::preprocess_symbol(a_symbol_with_origin const&, a_symbol*, a_completion_symbol_manager::a_state&, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, msvc::inclusive_offset_range_t, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>&, std::queue<a_symbol_with_origin, std::deque<a_symbol_with_origin, std::allocator<a_symbol_with_origin>>>&, std::unordered_set<a_symbol_with_origin, a_symbol_with_origin_hash, std::equal_to<a_symbol_with_origin>, std::allocator<a_symbol_with_origin>>&, unsigned long, std::set<edge::symbol const*, std::less<edge::symbol const*>, std::allocator<edge::symbol const*>>, bool)+3519
a_completion_symbol_manager::add_symbol_internal(a_completion_symbol_manager::a_state&, msvc::inclusive_offset_range_t, a_symbol)+1137
a_completion_symbol_manager::add_symbol(msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, msvc::inclusive_offset_range_t, a_symbol*)+263
edge::scoped_query_manager::update_fragment(edge::file_position const&, edge::file_position const&, edge::file_position const&, edge::update_fragment_options const&)+328
edge::an_edge_translation_unit_impl::update_range(edge::allocator*, snapshot::snapshot_session_t, edge::file_position, edge::file_position, edge::update_range_options const&, edge::file_position, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, an_array_list<edge::update_range_action*, std::allocatoredge::update_range_action*> const&, edge::query_action_data&)+1353
edge::translation_unit::update_range(edge::allocator*, snapshot::snapshot_session_t, edge::file_position, edge::file_position, edge::update_range_options const&, edge::file_position, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, an_array_list<edge::update_range_action*, std::allocatoredge::update_range_action*> const&, edge::query_action_data&)+137
edge_intellisense_server_impl::update_range(std::shared_ptredge::translation_unit const&, char const*, edge::update_range_options, snapshot::snapshot_session_t const&, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>&, msvc::strong_typedef<msvc::offset_traitsmsvc::offset_tag_t>&)+502
edge_intellisense_server_impl::handle_update_intellisense(cpp_intellisense::UpdateIntelliSenseRequest const&, cpp_intellisense::UpdateIntelliSenseResponse&, snapshot::snapshot_session_t const&)+575
cpp_intellisense::server_stub::handle_update_intellisense(msvc::deserializer_t&, msvc::serializer_t&)+312
msvc::base_channel_t::dispatch_message(std::vector<unsigned char, std::allocator> const&, std::vector<unsigned char, std::allocator>&)+2676
msvc::common_channel_t::perform_call(unsigned int, std::vector<unsigned char, std::allocator> const&)+70