Vscode-cpptools: GCC 8: IntelliSense suggestions don't work in files that contain std::map (anything depending on type_traits)

[Cre3per]

Type: LanguageService

Describe the bug

• OS and Version: x86_64 Linux 4.17.8-1-ARCH
• VS Code Version: 1.25.1
• C/C++ Extension Version: 0.17.7

To Reproduce
Steps to reproduce the behavior:

1. Create a new file (main.cpp)
2. Write

#include <map>

int main(void)
{
  // IntelliSense suggestions stop working after writing this line (and saving)
  std::map<int, int> mp{ };

  // If IntelliSense is still up, uncomment this loop
  // for (const auto el : mp)
  // {

  // }

  return 0;
}

After this, only VSCode suggestions show up

Removing the use of std::map and resetting the IntelliSense database fixes the problem until std::map is used the next time.

Relevant part of the log in Debug mode:

Checking for syntax errors: file:///<path>/main.cpp
queue_update_intellisense for files in tu of: <path>/main.cpp
  tag parsing file: <path>/main.cpp
sending 3 changes to server
Failed to read response from server: 18
Database safe to open

Expected behavior
IntelliSense suggestions should keep working

[sammko]

I observe the same behaviour with std::set.

#include <set>

int main() {
    std::set<int> s;
}

Here is a backtrace generated while editing the above code:

#0  0x0000000000835253 in add_symbol_to_overload_list ()
#1  0x00000000008357b6 in enter_overloaded_symbol ()
#2  0x0000000000638ff5 in decl_member_function_template ()
#3  0x0000000000629988 in class_member_declaration ()
#4  0x0000000000625963 in class_member_template_declaration ()
#5  0x000000000086f39a in template_declaration ()
#6  0x0000000000861ca0 in template_or_specialization_declaration ()
#7  0x0000000000860f8c in template_directive_or_declaration ()
#8  0x000000000062cbb1 in scan_class_definition ()
#9  0x000000000084abbb in f_instantiate_template_class_full ()
#10 0x00000000006fbb04 in cast_type_pre_check ()
#11 0x00000000006e4219 in scan_functional_notation_type_conversion ()
#12 0x00000000006d988c in scan_identifier ()
#13 0x00000000006d0639 in scan_expr_full ()
#14 0x00000000006d13fc in scan_decltype_operator ()
#15 0x000000000079ce75 in f_is_generalized_identifier_start ()
#16 0x00000000006b5a90 in decl_specifiers ()
#17 0x000000000068f8fd in type_name_full ()
#18 0x000000000067b7a6 in function_declarator ()
#19 0x0000000000680946 in r_declarator ()
#20 0x000000000067baf7 in declarator ()
#21 0x0000000000626a8a in class_member_declaration ()
#22 0x0000000000625963 in class_member_template_declaration ()
#23 0x000000000086f39a in template_declaration ()
#24 0x0000000000861ca0 in template_or_specialization_declaration ()
#25 0x0000000000860f8c in template_directive_or_declaration ()
#26 0x000000000062cbb1 in scan_class_definition ()
#27 0x000000000084abbb in f_instantiate_template_class_full ()
#28 0x0000000000889294 in f_type_has_default_constructor ()
#29 0x00000000006999f6 in scan_nonmember_declaration ()
#30 0x000000000082922c in decl_statement ()
#31 0x000000000082672e in statement ()
#32 0x0000000000824c81 in compound_statement_full ()
#33 0x00000000007342b0 in scan_function_body ()
#34 0x0000000000736224 in function_definition ()
#35 0x00000000006983a8 in scan_nonmember_declaration ()
#36 0x000000000069a503 in declaration ()
#37 0x000000000058b7a9 in compile_fragment((anonymous namespace)::a_fragment_buffer const&, a_canonicalized_file_name, unsigned long, unsigned long, unsigned long, bool, a_declaration_context const&, a_region_namespace_info const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, bool, bool, bool, bool*) ()
#38 0x00000000005893f8 in end_of_parse_notification ()
#39 0x00000000008836a9 in process_translation_unit ()
#40 0x0000000000613f17 in cfe_main ()
#41 0x00000000008a0596 in cfe_main_exception_handler ()
#42 0x0000000000614006 in edg_main ()
#43 0x000000000089b84c in edge_compiler_main(int, char const**) ()
#44 0x00000000005899b7 in preparse(int, char const**, a_scout_store*, edge::translation_unit*) ()
#45 0x0000000000551749 in a_compiler_thread::compiler_thread_routine(a_compiler_thread*) ()
#46 0x00000000005818fe in void* std::__1::__thread_proxy<std::__1::tuple<void (*)(a_compiler_thread*), a_compiler_thread*> >(void*) ()
#47 0x00007f07ab004075 in start_thread () from /usr/lib/libpthread.so.0
#48 0x00007f07aad3953f in clone () from /usr/lib/libc.so.6

[sean-mcmanus]

What library is providing the definition for map/set? Is this gcc/libc++ 8? We've received another report of a crash with that.

[sammko]

@sean-mcmanus Yes, it's gcc/libc++ 8.1.1 in my case.

[sean-mcmanus]

Okay, thanks a lot -- I got the repro. This is pretty bad. It doesn't repro with previous versions of the gcc headers.

[sean-mcmanus]

This is a regression from our previous release after we updated our parser code. So you can use our previous 0.17.6 version as a workaround, setting extensions.autoUpdate to false to avoid getting the newer version: https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.6 .

[sean-mcmanus]

The root cause is our compiler's lack of support for the __is_assignable intrinsic added to gcc-8. You can work around this via adding this define to your c_cpp_properties.json:
"__is_assignable(a, b)=true" (our previous version was more resilient to the missing intrinsic). Let us know if you notice any issues with this workaround.

Also, (at your own risk/discretion) you could also modify your gcc-8 type_traits headers to get rid of the __is_assignable intrinsic usage (see https://github.com/gcc-mirror/gcc/commit/b4d90ee21694777d1558cc9d2d29ac82cb7b168c ).

UPDATE: Our 0.17.8-insiders release with the gcc-8 type_traits crash fix is available at https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.8-insiders .

[huww98]

@sean-mcmanus This issue comes up again after upgrade to 0.18.1.

This does not work on 0.17.7, fixed on 0.18.0, but broken again on 0.18.1.

[sean-mcmanus]

@huww98 The only thing that changed in 0.18.1 is that we were incorrectly adding the -fms-extensions flag to non-MinGW compilers, so I'm not sure how 0.18.1 could have broken this -- only the Windows binary was changed. What OS are you on? What exactly is the bug/crash you are hitting?

[huww98]

@sean-mcmanus I'm on Windows and using WSL / Ubuntu 18.04 / g++-8.

I just copy and paste the code in the issue description, then IntelliSense stops working. And I received Failed to read response from server: 18 from output window, just as described above.

[sean-mcmanus]

@huww98 Can you attach a debugger to the Microsoft.VSCode.CPP.IntelliSense.Msvc.exe process before the crash occurs (i.e. you can comment out the code that causes the crash, and then edit the code to cause a crash with the debugger attached) -- and then provide the call stack? Do you know which header file is causing the crash? We are aware of a "high-hitting" crash involving "get_file_path_actual_case", so you could be hitting that.