Failed to query default include paths for use with compile_commands.json

[3v1n0]

Running vscode in ubuntu 16.04 (from snap package), when providing my compile_commands.json this extension complains about that, with no other infos.

So I can't really debug it (nor I can't find where this is emitted from, I only notice is in bin/Microsoft.VSCode.CPP.Extension.linux

This is weird, since clangd doesn't seem to complain about that when using vscode-clang.

Not sure if this is related, but I'm also having #1202 otherwise, but my includes look fine

gcc -Wp,-v -E -xc -x c++ /dev/null
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "/dev/null"

---

I've now noticed that I was getting a similar error an broken installation of clangd that I had locally, once I've properly installed the clang libraries, clangd worked fine. This is not still happening for this extension though, and it tries to load a definition where it should not:

[sean-mcmanus]

What compiler or script is being referenced in the "command" in your compile_commands.json? gcc or something else?

[3v1n0]

For reference my compile_commands.json are generated by both Meson builder and Bear, every line of it is generally something like:

{
  "directory": "/home/marco/Dev/GNOME/_BUILD/glib/tests/gobject",
  "command": "cc -c -DGLIB_DISABLE_DEPRECATION_WARNINGS -DG_LOG_DOMAIN=\\\"GLib\\\" -I. -I/home/marco/Dev/GNOME/glib/tests/gobject -I../.. -I../.. -I../../glib -I/home/marco/Dev/GNOME/glib/glib -I/home/marco/Dev/GNOME/glib -I/home/marco/Dev/GNOME/glib/gmodule -DG_ENABLE_DEBUG -pthread -g -g -O2 -o testgobject.o ../../../../glib/tests/gobject/testgobject.c",
  "file": "../../../../glib/tests/gobject/testgobject.c"
},

So the compiler is just the generic cc (which in this system is indeed gcc-5).

Speaking of which, would be possible to force this extension to use a different compiler or compiler stack for this? As sometimes I've to run other compiler versions or compilers installed in other PATH's (or in schroots, so with a bit different command line).

[sean-mcmanus]

@3v1n0 Your command looks good -- I don't know why our attempt to query the includePaths from "cc" is failing. @bobbrow Any ideas? We're in the process of adding a compilerPath setting for our next release, which will override the version we attempt to get from the compile_commands.json, so maybe that will be a workaround for you, although we do the same type of querying so it could still fail, but I've changed the error message to provide more info.

[3v1n0]

Mh, ok... Thanks, let me know if I can provide some better debugging bits, other than posting the error.

[FreddieChopin]

I'm getting the same error. With the compile_commands.json generated by CMake (project is building fine) I get this error when opening any file in the project. So I've edited down my file down to a single entry, with almost everything removed:

[
{
  "directory": "/home/freddie/Elektronika/ARM/Projects/STM32F4-mono-graphic-keypad",
  "command": "g++ -IWatchdogTimer",
  "file": "/home/freddie/Elektronika/ARM/Projects/STM32F4-mono-graphic-keypad/watchdogTimerManagerInstance.cpp"
}
]

I reset IntelliSense database, reopen the file and see Failed to query default include paths for use with compile_commands.json again, included file which is in the WatchdogTimer folder is not found.

I'm looking forward to next release with the new options, but I'm afraid these won't be enough for embedded projects which use cross-compilers which also need special flags. In my case I get different internal compiler defines depending on the flags I used. For example with arm-none-eabi-gcc -dM -E - < /dev/null I get slighly different set than with arm-none-eabi-gcc -dM -E -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 - < /dev/null and this is slightly changed when using arm-none-eabi-gcc -dM -E -mcpu=cortex-m4 -mthumb - < /dev/null. Will that be possible to put the path to compiler WITH the required flags in the new compilerPath property? If not, would it be possible to change it before the final release?

[sean-mcmanus]

@FreddieChopin Yeah, we've discussed having a generic compiler command line setting, but we didn't add it because we weren't sure of a scenario that required it. We have an insider build available with the compilerPath option, but there's no means to add additional flags that change the default compiler defines set: https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.0-insiders . So do you think adding the ability to setting compiler flags would fix your issues or are you experiencing other issues? The "Failed to query include paths" message means we failed to launch the compiler for some reason so it sounds like there might be some other bug. The insider build might give better error messages. I don't know yet if a command line setting will make it into the March or April updates.

[sean-mcmanus]

@3v1n0 Are you able to get things working using the compilerPath setting in https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.0-insiders ?

[FreddieChopin]

Generally there are two issues here - the first one is related to the compile_commands.json file not working for me at all. The second one is for automatically determining the compiler defines when using cross-compilers like arm-none-eabi-gcc. They are somehow related, but definitely separate problems (; I'll stick to the first one here. As for the second one, for me it would be enough to have the compiler path and it's "machine-level" flags in the same property. If you'd like to discuss that more, please let me know in which issue we could do that without spamming here.

I've installed the latest preview release 0.16.0-insiders, but the issue with parsing the compile_commands.json remains. The problem now is that there's no "C/C++" entry in the dropdown in Output tab, so I cannot see the errors... Maybe this is related to me having a "stable" vscode and "preview" of the extension? Only once - just after I installed it - I've seen this:

Failed to read response from server: 16
Failed to send request to server: 17 

I have absolutely no idea why this happens, however it happens whatever I do - whether the compile_commands.json file is the original one generated by CMake (example fragment below), or my edited simple single-entry one, with g++, gcc, clang, cc or the full path to my real compiler...

{
  "directory": "/home/freddie/Elektronika/ARM/Projects/STM32F4-mono-graphic-keypad/output",
  "command": "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/arm-none-eabi-g++   -I../ -I../board/include -I../CommandShell -I../fonts -I../images -I../lcd -I../ModbusMaster -I../RealTimeClock -I../WatchdogTimer -Iexternal/distortos/include -I../external/distortos/include -I../external/distortos/source/architecture/ARM/ARMv6-M-ARMv7-M/include -I../external/distortos/source/architecture/ARM/ARMv6-M-ARMv7-M/external/CMSIS -I../external/distortos/source/chip/STM32/include -I../external/distortos/source/chip/STM32/STM32F4/include -I../external/distortos/source/chip/STM32/peripherals/GPIOv2/include -I../external/distortos/source/chip/STM32/peripherals/SPIv1/include -I../external/distortos/source/chip/STM32/peripherals/USARTv1/include -I../external/distortos/source/chip/STM32/STM32F4/external/CMSIS-STM32F4 -I../external/distortos/source/board/ST_NUCLEO-F429ZI/include -I../external/mbmaster/include -I../mbmaster-integration    -Wall -Wextra -Wshadow -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g -ggdb3 -O2 -fno-use-cxa-atexit -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -std=gnu++11 -o CMakeFiles/STM32F4-mono-graphic-keypad.elf.dir/main.cpp.obj -c /home/freddie/Elektronika/ARM/Projects/STM32F4-mono-graphic-keypad/main.cpp",
  "file": "/home/freddie/Elektronika/ARM/Projects/STM32F4-mono-graphic-keypad/main.cpp"
},

Probably important - to actually check whether compile_commands.json is working, I remove everything from includePath and browse/path. Otherwise the includes sort-of-work, but just because they are found by name search in workspace folder.

If that is important (probably is) - I'm using Arch Linux, Linux 4.15.7-1-ARCH #1 SMP PREEMPT Wed Feb 28 19:01:57 UTC 2018 x86_64 GNU/Linux, vscode is from the AUR - visual-studio-code-bin 1.21.0-1.

[FreddieChopin]

Maybe this would be useful, so I attach the simplest test case of the problem.

$ tree
.
├── CMakeLists.txt
├── folder-a
│   └── header.h
├── folder-b
│   └── header.h
└── main.cpp
$ cat CMakeLists.txt 
cmake_minimum_required(VERSION 3.1)
project(cpp-parser)

add_executable(cpp-parser
        main.cpp)
target_include_directories(cpp-parser PRIVATE
        folder-b)
$ cat main.cpp 
#include "header.h"

int main(void)
{
    return 0;
}

Header files are empty.

$ mkdir output
$ cd output
$ cmake .. -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/freddie/test/cpp-parser/output
$ make
Scanning dependencies of target cpp-parser
[ 50%] Building CXX object CMakeFiles/cpp-parser.dir/main.cpp.o
[100%] Linking CXX executable cpp-parser
[100%] Built target cpp-parser

Now I create a default c_cpp_properties.json file and do this:

• remove "${workspaceFolder}" from includePath,
• remove "${workspaceFolder}" from browse/path,
• add "compileCommands": "/home/freddie/test/cpp-parser/output/compile_commands.json"

I close all files, Ctrl+Shift+P, reset intellisense database, reopen main.cpp. #include "header.h" is underlined with green wavy line, the error says:

#include errors detected. Consider updating your compile_commands.json or includePath. IntelliSense features for this translation unit (/home/freddie/test/cpp-parser/main.cpp) will be provided by the Tag Parser.
cannot open source file "header.h"

When I Ctrl+click it, it takes me to some random files with that name found in compiler paths, not the ones from the project.

I attach the whole workspace (after make clean) with all the relevant files. cpp-parser.zip

[sean-mcmanus]

The C/C++ tab won't appear until an error occurs (you can set the C_Cpp.loggingLevel to "Information" to make it appear). The 0.16.0-insiders should work identically with Insiders and non-Insiders of VS Code. The "Failed to read/send" usually means the Microsoft.VSCode.Cpp.Intellisense.Msvc process has crashed. Are you getting the "Failed to query" error still with the compilerPath set? compile_command.json is working for me on Linux so it seems like something special is occurring in your scenario. The issue with your test project seems like it may be due to https://github.com/Microsoft/vscode-cpptools/issues/1666 because you have 2 headers and it may be choosing the wrong translation unit, but I can double check that (if you don't still repro the issue by renaming one of the header files then it's a different issue).

I created bug https://github.com/Microsoft/vscode-cpptools/issues/1673 for the machine-level flag issue.

[sean-mcmanus]

I'm not able to repro the error you describe (with 0.16.0-insiders). Oh -- you don't want to remove stuff from browse.path, because that will make the features that depend on the symbol database to stop working (i.e. go to definition, ctrl+click) -- that setting is recursive so it's easier to configure. compileCommands just sets the includePath/defines, but browse.path still needs to have the root paths for all symbols. You don't seem to be hitting #1666.

[FreddieChopin]

The C/C++ tab won't appear until an error occurs (you can set the C_Cpp.loggingLevel to "Information" to make it appear).

OK, done that.

The "Failed to read/send" usually means the Microsoft.VSCode.Cpp.Intellisense.Msvc process has crashed. Are you getting the "Failed to query" error still with the compilerPath set?

With the settings from the testcase above, I don't get this error now. All I can see in the Output / C/C++ when I reset database, open main.cpp and then Ctrl+click on header.h include is:

Code browsing service initialized
Discovering files...
  Processing folder (recursive): /usr/local/include/
  Processing folder (recursive): /usr/lib/clang/5.0.1/include/
  Processing folder (recursive): /usr/include/
  Discovering files: 37986 file(s) processed
  0 file(s) removed from database
Done discovering files.
Parsing remaining files...
  Parsing: 0 files(s) processed
Done parsing remaining files.
Checking for syntax errors: file:///home/freddie/test/cpp-parser/main.cpp
3 include path suggestion(s) discovered.
Shutting down IntelliSense server: /home/freddie/test/cpp-parser/main.cpp
Checking for syntax errors: file:///usr/include/CLucene/snowball/runtime/header.h

The issue with your test project seems like it may be due to #1666 because you have 2 headers and it may be choosing the wrong translation unit, but I can double check that (if you don't still repro the issue by renaming one of the header files then it's a different issue).

Well. the whole point of the compile_commands.json for me is to properly detect which of the header files with identical names it should use. Otherwise compileCommands brings absolutely nothing more than the auto-search in ${workspaceFolder} in my case... I have a RTOS which can be configured for multiple different targets, which influences the include paths used during the build. So in my project there are multiple header files with identical names (for example each of 10 supported development boards provides leds.hpp header file), but the include paths given to the compiler (and saved in compile_commands.json should make it possible to detect which one is actually used.

But...

I renamed one header to header-a.h and the other one to header-b.h. Close files, reset database, open main.cpp. The #include is underlined by green wavy line, there's the same error in the tooltip. Ctrl+click on the include doesn't work.

I've extended my testcase to also have a XXX define. This also doesn't work:

• in header-a.h line 2 is grayed out, while line 4 is active,
• in main.cpp line 4 is grayed out, line 6 is activer. In both cases it should be the opposite.

Output / C/C++ says just:

Code browsing service initialized
Discovering files...
  Processing folder (recursive): /usr/local/include/
  Processing folder (recursive): /usr/lib/clang/5.0.1/include/
  Processing folder (recursive): /usr/include/
  Discovering files: 37986 file(s) processed
  0 file(s) removed from database
Done discovering files.
Parsing remaining files...
  Parsing: 0 files(s) processed
Done parsing remaining files.
Checking for syntax errors: file:///home/freddie/test/cpp-parser/main.cpp
0 include path suggestion(s) discovered.
0 include path suggestion(s) discovered.
0 include path suggestion(s) discovered.

I attach the modified test case if it's of any help. cpp-parser-1.zip

[FreddieChopin]

Oh -- you don't want to remove stuff from browse.path, because that will make the features that depend on the symbol database to stop working (i.e. go to definition, ctrl+click) -- that setting is recursive so it's easier to configure. compileCommands just sets the includePath/defines, but browse.path still needs to have the root paths for all symbols.

I get that and I would prefer not to remove that, but I cannot think about a reasonable way to test this with auto-search in ${workspaceFolder} enabled. Well - maybe the extended test case would be better here, because it has defines which cannot be auto-searched... Anyway - I've recreated the original settings file, just added my compileCommands - defines are not working still, the header is working, but this is trivial with the auto-search. Let me know how can I debug it to help you better and what info should I provide.

BTW - the compile_commands.json file is parsed, because if I introduce an error there, I see an error message right away. It just seems that nothing useful is parsed from this file /;

[sean-mcmanus]

I opened the cpp-parser-1 folder and modified the compile_commands.json and compileCommands to change the path to my own, but I'm still not reproing the bug. I'll try to see if anyone else can repro this. I don't think you're hitting the #1666 issue -- the symptom is that hovering over a number will show no tooltip (due to silent fall back to tag parser) and you wouldn't get any "cannot open" errors.

[FreddieChopin]

the symptom is that hovering over a number will show no tooltip (due to silent fall back to tag parser) and you wouldn't get any "cannot open" errors.

Actually if I hoover over the VALUEA or VALUEMAIN in main.cpp line 11 I see TWO tooltips at once, with both values.

[sean-mcmanus]

Yeah, that's falling back to the tag parser due to missing #include files. #1666 occurs when opening a header file (that doesn't belong to any translation unit).

You can set intelliSenseEngineFallback to "Disabled" to get the 1 VALUEA, assuming there's no other issue (i.e. I'm able to repro that via adding #include "foo").

[FreddieChopin]

You can set intelliSenseEngineFallback to "Disabled" to get the 1 VALUEA, assuming there's no other issue (i.e. I'm able to repro that via adding #include "foo").

Actually this visual issue is irrelevant right now. What I would like to achieve is to have compile_commands.json properly parsed so that:

• it would detect my compiler includes/defines (or at least some of them),
• it would be able to deal with multiple identical filenames in the project.

[3v1n0]

@sean-mcmanus I've tried that, but I'm getting another error now:

Quick info operation failed: FE: 'Compiler exited with error - No IL available'

Also I've to mention, that in my case I need to launch a compiler suite that runs inside a schroot, so I need to pass various flags, and then defining the compilerPath pointing to a bash script that actually calls something like:

/usr/bin/schroot -c unstable -- /usr/bin/gcc $*

In general so I'd need to define a binary and flags.

The same compiler environment gives some results when using vscode-clangd extension instead. Although some include errors are still shown by this extension (and for some reason I need to keep both enabled to get things work).

[sean-mcmanus]

@3v1n0 What is your compilerPath? It's supposed to be the actual path of the compiler, such as /usr/bin/gcc and not a script. We use that path for querying the compiler for the system includes and defines. We're planning to add the ability to pass other flags, but that should only be needed when the default compiler defines are not correct.

[3v1n0]

As said, my actualy compiler is inside a different schroot, then I can't call it directly, but i need to invoke it in such way.

However, setting that to a script (that just calls gcc with such parameters, so it's basically only a script) now it seems to work in terms of no errors reported by the problems panel, but there are no completions computed or anything smarter done with symbols, it seems.

Adding vscode-clangd to the mix, as said fixes that. Quite weird, but i know it's a non-trivial setup.

[FreddieChopin]

Is the data which gets parsed from compile_commands.json saved somewhere, so that I could see whether there's anything reasonable? Or maybe it gets loaded to RAM only and there's no way to verify what's going on? Maybe it would be possible to see something with the "Developer Tools" of vscode?

I'm risking a wooden stick straight through the heart, but...

Eclipse does things similarly to what you try to achieve. There's "output parser" provider, which scans the compilation commands for -I and -D flags - this would be the equivalent of compile_commands.json, but not requiring the actual file. Generally the file seems easier to work with, as it also has info about current folder, while some compilation setups in Eclipse may get a bit crazy with the actual cwd - that's why mentioned parser from Eclipse also has a magic option "Use heuristics to resolve paths". However - not requiring a file means that you don't need any support for its generation in the build tool you are using.

Then there's also a "builtin compiler settings" provider, which is probably close to what you try to automatically do with compiler detected from compile_commands.json and now with the compilerPath property. The significant difference here is that in Eclipse you just tell it how to execute the compiler to get all these magic settings by editing the call which - by default - is in the form ${COMMAND} ${FLAGS} -E -P -v -dD "${INPUTS}". In this case it is trivial to replace this with whatever you like - you can use a real compiler (typical scenario), but you can as well use a script which just prints whatever is needed (in proper format obviously) or you could use a complex compiler call like @3v1n0 above or add any strange machine-level flags like I need. Actually you can also add -std=c++11 -std=c99 here and select the standard, which for me seems easier than the approach you implemented in 0.16.0 - at least because I could select between gnu++11 and c++11 manually, which would not be possible with cppStandard. I think it would more flexible to have two compilerPath properties - one for C and one for C++ - which would also accept flags and use shell substitution (pipe and redirection for echo | compiler -with -flags or compiler -with -flags < /dev/null), so that you could use that in any non-standard scenario you want.

Obviously Eclipse also has "user setting entries", which would be the equivalent of includePath and defines.

Another significant difference is that Eclipse saves what it discovered and you can easily inspect the data it uses for each file from the project. This is something which would be useful here, as currently I have no idea whether the parser in cpptools detects nothing, detects garbage or detects correct data but fails to use it. That's why it's so hard to debug the problem we are seeing here, as generally the only info I can provide is "it's not working for me" );

[FreddieChopin]

I asked my brother to check the testcase I uploaded earlier and... it works for him with no issues - defines are discovered in the compile_commands.json, as well as the include paths. The funny thing is that we have almost identical PCs with almost identical system (we both use Arch Linux). I have absolutely no idea what's wrong here and how to find the root cause of the problem /;

[sean-mcmanus]

@3v1n0 Okay, your scenario should be do-able after we enable args to be added to compilerPath. I believe a workaround would be to create a script with no args that calls the other script with args.

@FreddieChopin The compile_commands.json is just parsed in memory, but you can set the C_Cpp.loggingLevel to 6 to see the "sending compilation args for" message, which show what we have parsed and are sending to the intellisense engine process (which is the one that is sending back the cannot open header.h message), but be sure to remove that logging level when you're done, because it could slow down operations a lot. I think this logging is only in the version of 0.16.0-insiders we released on the 9th (not the 8th).

The reason we didn't want an open ended -std flag being used is that we have to manually convert the value to flags our EDG compiler understands, and that hasn't been done yet for gnu++11, c++20, C++/CLI, etc. We can look into adding that std version later.

We considered having 2 compilerPaths for C and C++, but we couldn't think of a compelling reason for that since gcc/clang support both languages anyway, and we figured if necessary that could be achieved via having 2 different configurations (we initially had only 1 stdVersion as well).

[FreddieChopin]

After setting debug level to "6" this is what I got in the Output / C/C++ (close all, reset database, wait until it finishes, clear log [*], open main.cpp from the testcase, default c_cpp_properties.json, with added compileCommands). https://gist.github.com/FreddieChopin/fcb62ebcaf49a7bbcc7a0ec0b0572a8b

Interestingly it seems the problem magically fixed itself, as my latest testcase seems to work fine now /; In my real project I see that proper paths are discovered, but cpptools still cannot deal with multiple headers with the same name - even though there is exactly one such header in the include paths it sees, when I Ctrl+click it it presents a choice where I have to decide which file I really want. It wouldn't be so bad if the file that is actually used would be the first one, but it seems the list is sorted alphabetically. I'll investigate a bit more, as all of that is very strange now... Anyway - would that be possible for cpptools to handle multiple headers with identical names properly? If it could and if we would be able to specify machine-level compiler flags then it would be really great <:

[*] - if there's anything important in this part, let me know and I'll publish that too, but this part is ~115k lines, mostly about removing/enumerating headers found in standard paths.

[sean-mcmanus]

Ctrl+click is not hooked up to IntelliSense yet (hover/completion is), which is why it'll give fuzzy/multiple results. IntelliSense in general works with same-name files -- if you hover and it gives 1 result then IntelliSense is working (I doesn't sound like you're hitting #1666). Yeah, your log appears correct now.

[3v1n0]

As per the script, launching my command, it's something I already did.

However in the insider version I can download from github (64bit: md5sum 0a8a14a711634924682237f3664b74c0), the loglevel 6 isn't available, apparently.

[sean-mcmanus]

@3v1n0 Cpp.loggingLevel "6" is a hidden value that is accepted, but not part of the pre-defined enums, so you can just ignore the warning.

[3v1n0]

So, when using the script I'm also getting a weird result in such log, and it seems that it still loads the host compiler (gcc-5), while I need the 7 version.

This is instead when using a C wrapper as compiler : https://pastebin.ubuntu.com/p/T38VHZJvXs/

I don't see any particular error a part from one sometimes showing, but what I believe is happening there is that this extension isn't actually using the compiler I passed for doing proper analysis and thus it won't use the right paths. For example, the compiler will expose that /usr/include/x86_64-linux-gnu/c++/7 as one of the paths it should use (when doing such as ./schroot-compiler -Wp,-v -E -xc -x c++ /dev/null), but then I've like the impression that vscode will try to open that file, but that doesn't exist, as that path is relative to the schroot (so having an option to make it know the actual prefix to preopone to any file would be enough).

So basically, this extension should only parse the output of the compiler used for the analysis (and also why clangd works in this case).

I know this is more complicated case, but I guess that using a container to do the compilation job while developing in the host is something that should be good practice the only option when developing something in different devices.

[sean-mcmanus]

@3v1n0 So you're not seeing any errors with loggingLevel 6? Oh yeah, we have a bug which causes the errors that occur too early to not appear -- making a change to the compilerPath setting afterwards should get an error to appear. We do only parse the output of the compiler (for includes/defines) and we don't try to open files. We have a fix that enables command line args, but I'm not sure when we're releasing it yet.

Oh, I just tried using a script and it doesn't appear to work on Windows or Linux. We use the path to create a child process and read stdout from it and that appears to not be working if a script is used...and on Linux we don't log an error, because the output is just bogus so it silently falls back to defaults. Maybe the script needs to have some stdout forwarding or something.

[3v1n0]

Yeah, in fact as I said using a C wrapper more than a script seemed better (I just linked the wrong thing before, I've used something like this: https://pastebin.com/w0herDKe).

It looks like Something is happening however... And I'm getting some completions (not like clangd, though yet).

Disabling debug output, I'm still getting this error though:

Quick info operation failed: FE: 'Compiler exited with error - No IL available'

[sean-mcmanus]

The "No IL available" occurs when our parser ends up generating no output (i.e. when it's parsed after the file is opened). I haven't seen reports of that error in a while -- the more common error would be to just crash.

[FreddieChopin]

Let me get back to this issue (;

For now it seems that sometimes IntelliSense for files is working fine, while sometimes it's not. And I'm talking about exactly the same file in exactly the same project. One day I see hints about arguments for a function, another time nothing is working and all I see is "failed to get response from server" or sth like that. This "another time" may be another day or just "5 minutes after it was working fine".

So I close everything, set log level to "6", reset the database, wait for a pretty long time (~5 minutes?), clear log output, open my main.cpp file, check the log and get... absolutely nothing, it seems that the extensions crashed completely this time (yet it was parsing the files for quite long just a second ago). When I would like to see a suggestion for function argument or sth all I see is "Loading..." in the tooltip.

So I close every editor, close vscode, reset the database, wait again and after a much shorter time now (maybe 30 seconds, full of Unable to add file to database, error = 0x8064000a: ... for [probably] every file) I see this in the log (cleared before opening main.cpp)

https://gist.github.com/FreddieChopin/5561d6963c1c102af22647143be2daaf

After I close the file and open it again, the log is similar, but the trailing part is a bit different now:

  define: __GXX_TYPEINFO_EQUALITY_INLINE=0
  define: __ELF__=1
  define: __USES_INITFINI__=1
  stdver: --c++11
IntelliSense client is currently disconnected
textDocument/codeAction
cpptools/activeDocumentChange
cpptools/textEditorSelectionChange
cpptools/textEditorSelectionChange
Unable to add file to database, error = 0x8064000a: /home/freddie/Elektronika/ARM/Projects/CWC-STM32F4-mono-graphic-keypad/main.cpp
textDocument/codeAction
textDocument/hover
textDocument_hover(): [27, 25]
IntelliSense client is currently disconnected
IntelliSense client not available, using Tag Parser for quick info.
using Tag Parser for quick info
textDocument/hover
textDocument_hover(): [27, 26]
IntelliSense client is currently disconnected
IntelliSense client not available, using Tag Parser for quick info.
using Tag Parser for quick info

(the messages about "hover" appear when I move my mouse over the code)

I close and reopen it again, and there's absolute silence in the log, even if I open another .cpp file. The last lines in the log are:

  define: __ELF__=1
  define: __USES_INITFINI__=1
  stdver: --c++11
  File added. Time stamp: 1521368902
IntelliSense client is currently disconnected
textDocument/codeAction
cpptools/activeDocumentChange
cpptools/textEditorSelectionChange
cpptools/textEditorSelectionChange
Unable to add file to database, error = 0x8064000a: /home/freddie/Elektronika/ARM/Projects/CWC-STM32F4-mono-graphic-keypad/main.cpp
textDocument/codeAction
textDocument/didClose
Shutting down IntelliSense server: /home/freddie/Elektronika/ARM/Projects/CWC-STM32F4-mono-graphic-keypad/main.cpp
terminating child process: 8869
still alive, killing...
not exited yet. Will sleep for 1 seconds and try again
Closing the communication channel.

At this point even if I use the "reset database" command absolutely nothing happens.

My properties file looks like this now:

        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}",
                "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0",
                "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0/arm-none-eabi/thumb/v7e-m/fpv4-sp/hard",
                "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0/backward",
                "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/include",
                "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/include-fixed",
                "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include"
            ],
            "defines": [],
            "intelliSenseMode": "clang-x64",
            "browse": {
                "path": [
                    "${workspaceFolder}",
                    "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0",
                    "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0/arm-none-eabi/thumb/v7e-m/fpv4-sp/hard",
                    "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include/c++/7.3.0/backward",
                    "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/include",
                    "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/include-fixed",
                    "/home/freddie/arm-none-eabi-gcc-7.3.0-180127/bin/../lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            },
            "compilerPath": "/home/freddie/test/arm-none-eabi-g++-m4-fpu.sh",
            "cStandard": "c99",
            "cppStandard": "c++11",
            "compileCommands": "${workspaceFolder}/output/compile_commands.json"
        },

And the magic script I use for querying the compiler (arm-none-eabi-g++-m4-fpu.sh):

#!/bin/sh

~/arm-none-eabi-gcc-7.3.0-180127/bin/arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 $@

Any ideas what's going on here and what info should I provide to help you narrow it down?

EDIT:

This issue is really hard to narrow down, as it seems like some random thing is going on here. I've deleted my entire configuration folder (/home/freddie/.config/Code), then I open fresh vscode, open my project, open a few files in it and the log says:

Failed to read response from server: 18
Failed to send request to server: 3
Failed to read response from server: 6
Failed to read response from server: 18
Failed to read response from server: 18

What I noticed is that at the bottom right corner there's a "parsing progress" icon, which suggests that the extension has to parse about 2000 files, which takes quite a lot of time. This icon is visible only when a .cpp / .c / [other-source-code-extensions] is open - if I close the editors or just some other file is opened (like a .json) the icon is hidden. It seems it is hidden also if I focus the "console" or "output" tab. Fortunately I think the parsing continues in the background anyway - when the icon reappears the number of parsed files is much higher than it was previously. This icon sometimes disappears even though a .cpp file is open in editor, as if the extension crashed. In that case I either see absolutely no IntelliSense suggestions, of some really limited info (for example it suggests global variables, failing to suggest a local one defined 2 lines above the cursor).

While the parsing is progressing (the icon is visible), I see the errors mentioned above. If the parsing eventually ends successfully, when I open a new .cpp file I sometimes see the "error 18" anyway, however IntelliSense seems to work correctly (at least with my limited testing now). Unless it crashed earlier, in which case it's pretty hard to get it back to a working state.

Maybe all the problems have to do something with a case when the user wants to start coding while the parsing in the background is still progressing? It seems the operation takes some time (a few minutes at least), however it's really hard to tell that it's the case, as the "parsing progress" icon is sometimes hidden.

[sean-mcmanus]

@FreddieChopin Sorry that you're experiencing reliability issues. It sounds like you're hitting 2 issues, but I don't think they're related.

1. The "Failed to read/send" and "IntelliSense client is currently disconnected" means the IntelliSense process is crashing. We have code that will restart the crashed process after an edit occurs. We've been gradually fixing the highest hitting crashes but there are still a large number of IntelliSense crash "buckets" (i.e. code that can cause our parser to crash, typically involving gcc library code that our parser hasn't been hardened against). If you're able to get a repro or a core dmp with the call stack of the crashing process that could help us fix the crash. We have crash logging on Windows and Mac, but not Linux (so far the Linux crashes have also appeared on Mac or Windows so adding crash call stack logging for Linux hasn't been a priority).

2. Tag Parser failure: The 0x8064000a is strange -- it appears to be an e_pending error, but I don't see where that could be occurring. The error will cause symbols in the file to not be parsed (i.e. for go to definition, but not IntelliSense-based stuff). All operations should be doable while the database icon is in the bottom right. The parsing should usually only be a one-time operation and then future workspace loading should just have a quick "discovering" phase. The number of files needed to parse can increase as more new #include files are found in files. We might need a repro to fix this.

We haven't seen any spike in crashes from 0.16.0-insiders yet, but the usage is low, so we'll continue to monitor 0.16.0 when it's released to see if there are any spikes in crashes.

[FreddieChopin]

If you're able to get a repro or a core dmp with the call stack of the crashing process that could help us fix the crash. We have crash logging on Windows and Mac, but not Linux (so far the Linux crashes have also appeared on Mac or Windows so adding crash call stack logging for Linux hasn't been a priority).

So I'm guessing that on Linux there's no straightforward way to get a core dump when the extension crashes, right? Or maybe there's a way to do that? I'd be grateful for some info how to do it, if it's possible at all for Linux. If not, I'll try to create a reproducible test case.

[sean-mcmanus]

@FreddieChopin To get a call stack of the crashing IntelliSense process, you just need to attach a debugger. There are various methods of doing this. The way I got it to work is to open the launch.json, click Add Configuration and select "(gdb) attach", then set the program property to the path to the Microsoft.VSCode.CPP.IntelliSense.Msvc.linux process, then attach to the process and do whatever to repro the crash. It should mention a segmentation fault in the Debug Console and the Call stack window should show the call stack in one of the threads (you should also see "Symbols loaded" message or there's some problem). You should make sure the process id is the correct one (i.e. not for the Microsoft.VSCode.CPP.Extension.linux process). Let me know if you have any problems getting this to work. The repro I use to generate a crash is hovering over a "_Complex c;" code in a .c file.

Other users have configured their tools to generate a core dump, but I haven't investigated how to do that yet (since the attach method works for me): https://stackoverflow.com/questions/17965/how-to-generate-a-core-dump-in-linux-when-a-process-gets-a-segmentation-fault .

You'll probably only want to have 1 C/C++ file open or there will be multiple IntelliSense processes. If the process crashes on opening of the file before the attach can be done, you may need to use another method (I don't think our release bits have a way to delay the IntelliSense process launching to enable attaching before a crash).

[FreddieChopin]

Is this helpful (this is with the most recent "insiders" release)?

libpthread.so.0!pthread_cond_wait@@GLIBC_2.3.2 (Unknown Source:0)
neosmart::WaitForMultipleEvents(neosmart::neosmart_event_t_**, int, bool, unsigned long, int&) (Unknown Source:0)
microsoft::vc::alertable_event::wait_for_multiple(microsoft::vc::alertable_event**, unsigned long, bool, unsigned int) (Unknown Source:0)
comm_server::wait_for_requests() (Unknown Source:0)
main (Unknown Source:0)

Debug console:

=thread-group-added,id="i1"
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
[New LWP 1901]
[New LWP 1902]
[New LWP 1903]
[New LWP 1904]
[New LWP 1905]
[New LWP 1906]
[New LWP 1907]
[New LWP 1908]
[New LWP 1909]
[New LWP 1910]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007f26229803bd in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
Loaded '/usr/lib/libm.so.6'. Symbols loaded.
Loaded '/usr/lib/libpthread.so.0'. Symbols loaded.
Loaded '/usr/lib/libc.so.6'. Symbols loaded.
Loaded '/usr/lib/libdl.so.2'. Symbols loaded.
Loaded '/usr/lib/librt.so.1'. Symbols loaded.
Loaded '/usr/lib/libgcc_s.so.1'. Symbols loaded.
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
[Switching to thread 11 (Thread 0x7f261d78f700 (LWP 1910))](running)
=thread-selected,id="11"

Thread 1 "Microsoft.VSCod" received signal SIGINT, Interrupt.
0x00007f26229803bd in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)

Thread 1 "Microsoft.VSCod" received signal SIGTERM, Terminated.
[Switching to Thread 0x7f26230c4740 (LWP 1899)]
0x00007f26229803bd in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0

[FreddieChopin]

ping? (;

[sean-mcmanus]

Oh, I completely missed your message 4 days ago so thanks for pinging (I'm not sure why that happens sometimes).

That doesn't look like a crash. It looks like an intentional termination of the IntelliSense process by the main extension process, such as on file closing. When is this occurring? Usually crashes occur on file opening or after using IntelliSense-based features like hover.

[FreddieChopin]

It's hard to tell... For some time suggestions are working fine and then they just stop. I usually notice when there are no suggestions for function arguments. From your post it seems that to track the crash (assuming there is one) I would have to keep working with single file (or just not closing any editor), right?

[sean-mcmanus]

Yeah, for getting the call stack of a crashing IntelliSense process, you'll want to keep the file open until the crash occurs. You can switch between multiple files though, but each individual file should spawn a new IntelliSense process so you might have to attach multiple debuggers if you're not sure which one will crash. However, if you have too many files open (based on CPU cores and memory usage), then we'll start closing IntelliSense processes on file switching...in the future we may remove the core limit and expose the memory limit as a setting to avoid unnecessary reprocessing.

Getting crashing data on Mac/Windows is easier because the OS has support for automatically generating crash logs/dmps. Adding our own crash call stack logging on Linux is on our low pri backlog.

[FreddieChopin]

Another interesting observation now. Intellisense does not work for some files at all, no matter what I do.

I open some file which causes no problem, and in the log I see:

...
  define: __GXX_TYPEINFO_EQUALITY_INLINE=0
  define: __ELF__=1
  define: __USES_INITFINI__=1
  stdver: --c++11
queue_update_intellisense for files in tu of: /home/freddie/Elektronika/ARM/Projects/CWC-STM32F4-mono-graphic-keypad/lcd/Erc1601602.cpp
textDocument/codeAction
cpptools/activeDocumentChange
cpptools/textEditorSelectionChange
cpptools/textEditorSelectionChange
textDocument/codeAction
About to fork
fork complete (parent process, child pid = 26205)
result=86636

Waiting for child process to complete
terminating child process: 26205
errorSquiggles count: 0

Suggestions for function arguments work perfectly fine. Then I open main.cpp file and the log says:

...
  define: __ELF__=1
  define: __USES_INITFINI__=1
  stdver: --c++11
queue_update_intellisense for files in tu of: /home/freddie/Elektronika/ARM/Projects/CWC-STM32F4-mono-graphic-keypad/main.cpp
textDocument/codeAction
cpptools/activeDocumentChange
cpptools/textEditorSelectionChange
cpptools/textEditorSelectionChange
textDocument/codeAction
Failed to read response from server: 18

Suggestions for function arguments don't work. I switch to another file - works. Get back to this one - doesn't work. Maybe there's no crash, but somehow the parser doesn't like some of my files?

It is very hard to narrow it down. I've identified two source lines that cause the problem. If I comment out both of them, then the parser starts working for this file. However if I remove everything from this file, leaving only these two problematic lines and the headers that are required (4 of them), then it works fine. I've tried to do that with attached debugger, but I could not see any crash there. Any idea how to narrow it down?

[sean-mcmanus]

The 18 corresponds to the "updating" or parsing of the file, so IntelliSense is crashing while doing that. If you can attach the debugger with the code disabled such that it doesn't crash and then re-enable the code so that it crashes, I think that should enable you to get a call stack. Is that what you tried and it didn't crash? And I assume your using a 0.16.0 insiders version, right? We fixed a high hitting crash in that one.

[FreddieChopin]

OK, with your suggestions I think I got an exception now.

Debug console:

=thread-group-added,id="i1"
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
[New LWP 3337]
[New LWP 3338]
[New LWP 3339]
[New LWP 3340]
[New LWP 3341]
[New LWP 3342]
[New LWP 3343]
[New LWP 3344]
[New LWP 3345]
[New LWP 3346]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007fa578f9c3bd in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
Loaded '/usr/lib/libm.so.6'. Symbols loaded.
Loaded '/usr/lib/libpthread.so.0'. Symbols loaded.
Loaded '/usr/lib/libc.so.6'. Symbols loaded.
Loaded '/usr/lib/libdl.so.2'. Symbols loaded.
Loaded '/usr/lib/librt.so.1'. Symbols loaded.
Loaded '/usr/lib/libgcc_s.so.1'. Symbols loaded.
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
[Switching to thread 11 (Thread 0x7fa56f7fe700 (LWP 3346))](running)
=thread-selected,id="11"

Thread 11 "Microsoft.VSCod" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa56f7fe700 (LWP 3346)]
0x00000000008335a8 in have_member_access_from_class_scope ()
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)

Call stack:

have_member_access_from_class_scope (Unknown Source:0)
have_particular_member_access_privilege (Unknown Source:0)
have_access_across_path (Unknown Source:0)
have_access_across_derivations_helper (Unknown Source:0)
reference_to_implicitly_invoked_function (Unknown Source:0)
expr_reference_to_implicitly_invoked_function (Unknown Source:0)
scan_ctor_arguments (Unknown Source:0)
prep_list_initializer (Unknown Source:0)
convert_initializer (Unknown Source:0)
braced_initializer (Unknown Source:0)
braced_mem_initializer (Unknown Source:0)
scan_mem_init_args (Unknown Source:0)
ctor_initializer (Unknown Source:0)
scan_function_body (Unknown Source:0)
parse_constexpr_function_if_needed (Unknown Source:0)
do_constexpr_ctor (Unknown Source:0)
interpret_constexpr_ctor (Unknown Source:0)
fold_constexpr_ctor (Unknown Source:0)
alloc_expr_ctor_dynamic_init (Unknown Source:0)
scan_ctor_arguments (Unknown Source:0)
prep_list_initializer (Unknown Source:0)
convert_initializer (Unknown Source:0)
braced_initializer (Unknown Source:0)
braced_mem_initializer (Unknown Source:0)
scan_mem_init_args (Unknown Source:0)
ctor_initializer (Unknown Source:0)
scan_function_body (Unknown Source:0)
parse_constexpr_function_if_needed (Unknown Source:0)
do_constexpr_ctor (Unknown Source:0)
interpret_constexpr_ctor (Unknown Source:0)
fold_constexpr_ctor (Unknown Source:0)
alloc_expr_ctor_dynamic_init (Unknown Source:0)
scan_ctor_arguments (Unknown Source:0)
prep_list_initializer (Unknown Source:0)
convert_initializer (Unknown Source:0)
braced_initializer (Unknown Source:0)
braced_mem_initializer (Unknown Source:0)
scan_mem_init_args (Unknown Source:0)
ctor_initializer (Unknown Source:0)
scan_function_body (Unknown Source:0)
process_deferred_class_fixups_and_instantiations (Unknown Source:0)
get_definition_of_class (Unknown Source:0)
scan_field_selection_operator (Unknown Source:0)
scan_expr_full (Unknown Source:0)
scan_expr_as_init_component (Unknown Source:0)
prescan_initializer_for_auto_type_deduction (Unknown Source:0)
initializer (Unknown Source:0)
scan_nonmember_declaration (Unknown Source:0)
decl_statement (Unknown Source:0)
statement (Unknown Source:0)
compound_statement_full (Unknown Source:0)
statement (Unknown Source:0)
compound_statement_full (Unknown Source:0)
scan_function_body (Unknown Source:0)
end_of_parse_notification (Unknown Source:0)
process_translation_unit (Unknown Source:0)
edg_main (Unknown Source:0)
edge_compiler_main(int, char const**) (Unknown Source:0)
pre_parse(int, char const**, a_scout_parser_interface&, edge::translation_unit*) (Unknown Source:0)
a_compiler_thread::compiler_thread_routine(a_compiler_thread*) (Unknown Source:0)
void* std::__1::__thread_proxy<std::__1::tuple<void (*)(a_compiler_thread*), a_compiler_thread*> >(void*) (Unknown Source:0)
libpthread.so.0!start_thread (Unknown Source:0)
libc.so.6!clone (Unknown Source:0)

The code fragments which cause problems:

int main()
{
    {
        const auto ret = watchdogTimerManagerInstance.initialize(std::chrono::seconds{10}); // <== THIS
        assert(ret == 0 && "watchdogTimerManagerInstance.initialize() failed");
    }
    // ...
    {
        const auto ret = modbusMasterInstance.open(0, 115200, distortos::devices::UartParity::none); // <== THIS
        assert(ret == 0 && "modbusMasterInstance.open() failed");
    }

    // ...
}

However it is quite possible that the real problem is caused by initializers for these two objects - these are in two completely separate .cpp files. The .cpp and .hpp files for modbusMasterInstance have the same problem, while the ones for watchdogTimerManagerInstance - don't. This brings me to another wild guess, that this may all be related to things like std::chrono::seconds{10} (used directly in the line above) and std::chrono::milliseconds{100} (used in initializer of subobject for modbusMasterInstance).

Related function declaration:

int initialize(distortos::TickClock::duration period);

distortos::TickClock::duration -> https://github.com/DISTORTEC/distortos/blob/master/include/distortos/TickClock.hpp#L39 (for this particular project period is 1/1000, typical std::chrono::duration values - like std::chrono::seconds - are convertible to distortos::TickClock::duration).

Related initializer for the second problematic object:

namespace
{

BlinkingLed rtuBlinkingLed {distortos::board::leds[0], std::chrono::milliseconds{100}}; // <== HERE

}   // namespace

ModbusMaster modbusMasterInstance {rtuBlinkingLed};

This std::chrono thing may be related, because if I remove these parts (which actually causes the build of project to fail, but I guess this is not a big issue for IntelliSense), the problem seems to go away (but I'm not sure whether it happens always, as with the insiders version it probably did not, while now with stable 0.16.0 it did). However I have to disable whole line with rtuBlinkingLed object - removal of one or both arguments is not enough, but the constructor for BlinkingLed class also has distortos::TickClock::duration as one of arguments.

I was using the latest "insiders" preview of 0.16.0, but now I tried with released 0.16.0 (stable) and the problem persists. Let me know if there's anything more I could do to help you with finding the real root cause of the problem.

[sean-mcmanus]

@FreddieChopin Thanks a lot for the repro details. I filed a bug on this "have_member_access_from_class_scope" crash 5 months ago with the VS 2017 team which this issue is inherited from (the bug started reproing in our C/C++ extension around the same time). I will try harder to get them to fix it. It's the top hitting crash on the VS side with the latest 15.6 release so it seems like it should be given priority by them to finally fix.

[3v1n0]

I'm still stuck with this issue... I see that in some cases the right compilation rules are used, but then it fails building with no errors (on debug "6").

Without setting the debug flag, I just get the error Compiler exited with error - No IL available.

Maybe the easiest workaround for my case would be to have the ability to set a root folder on which rebase all the includes that gcc returns. As when I call the gcc from the schroot, the one that is /usr/include for it, it's actually $SCHROOT_PREFIX/usr/include for vscode that runs outside that scope.

In general, however, I think that having support for clangd directly would be the best way.

PS: This is a multi-folder workspace, so I'm not sure if it should affect anything, or just using ${workspaceFolder} is enough.

[sean-mcmanus]

@3v1n0 Do you mean a --sysroot option? You should be able to add this flag after your compiler in the compilerPath to get this behavior, although I haven't tested it to be sure.

Multi-folder should work okay.

[3v1n0]

Mh, that seem to give some results in a project, thanks.

[FreddieChopin]

@sean-mcmanus - any news about the "have_member_access_from_class_scope" crash? I've now tried with the latest version of vscode and the extension - unfortunately the situation did not improve. Maybe there's a workaround for the problem or some other way to avoid it?

[sean-mcmanus]

@FreddieChopin The bug is assigned to a dev on the VS C++ team...he's been busy with other stuff for VS 15.7 so there's no update yet or known workaround.

[FreddieChopin]

hi there! any chance for a status update about this problem?