Adding includePath "third_party/eigen3" to tensorflow breaks IntelliSense with "No IL available" or "#include errors detected"

[sean-mcmanus]

1. Use the GitHub TensorFlow project. Add the includePath to "third_party/eigen3" (the bug doesn't repro without this path).
2. Open tensorflow/c/c_api_functions.cc .

Bug: IntelliSense completely fails with no error squiggles. Hover shows Quick info operation failed: FE: 'Compiler exited with error - No IL available'. If the IntelliSenseEngine fallback is enabled it will show "#include errors detected", but it won't list which include files can't be found. If that eigen3 folder is removed then a bunch of error squiggles are shown, as expected.

Another user-reported issue with a different symptom is at https://github.com/Microsoft/vscode-cpptools/issues/2960 .

[davidwin]

Has there been any progress with the No IL available error? I'm seeing this when I add the system root of an embedded system to the include paths in some way, so I assume that there is some problem parsing certain C constructs. I have set the log level to Debug for C/C++ and don't get any more than the above error message. I originally thought it was a problem with the compiler choking on --sysroot supplied on the compilerPath command line, but even adding the system root (with usr/include appended) as a normal include path in compile_commands.json results in the same IntelliSense compiler crash. I'm running the language server in Remote WSL mode if that is any help. It is a sizeable project, so pinning down exactly which file it is that breaks the compiler is going to take some time...

[sean-mcmanus]

"No IL available" is a generic symptom, so your repro (root cause) might be different. I don't believe this particular issue has been investigated yet.

Are you getting an actual crash? If so, can you attach a debugger to get a call stack? That would give us more info, but we still might need a repro.

The file that is causing the problem should be the source file that is opened or any headers it includes so the size of the project shouldn't matter, unless you're referring to a crash that occurs while "tag parsing", which would crash Microsoft.VSCode.CPP.Extension and could occur when parsing any file in a workspace (although we attempt to not reparse that file the 2nd time if we detect a crash). You can pass the -E flag to gcc while compiling the source you should be able to generate a single TU to repro the crash, which can make creating an isolated repro easier.

[davidwin]

Thanks for the quick response! I've managed to narrow it down to a very simple repro case, which is a header recursively including itself. It happens in the foreign sysroot's bits/wordsize.h, which contains the following code:

#ifndef __arm__
#include <bits/wordsize.h>
#endif

There are no include guards preventing a recursive inclusion of the same file, which makes the IntelliSense compiler crash. I realize that I would end up with an error of some kind anyway in this situation, but the crash seems to disable all completion and diagnostics completely instead of resorting to the tag parser.

Should I perhaps create a separate issue for this?

A related question is, if I was able to supply the path to a proper ARM cross compiler in compilerPath, would IntelliSense have a chance to work then, with a sysroot for an ARM system? What does "x64" in the gcc-x64 setting for intelliSenseMode mean? As I've understood the workings of the IntelliSense compiler, it essentially runs compilerPath with the -v -dM -E flags appended to get the initial preprocessor state. If the state is for an ARM compiler, is there a huge conflict with the IntelliSense mode being for x64 or x86?

[sean-mcmanus]

I'm not getting a crash -- I get #include file … includes itself and IntelliSense functionality stops working. VS has the same behavior. Are you seeing different behavior?

We haven't added ARM intelliSenseModes yet (https://github.com/microsoft/vscode-cpptools/issues/4271). The "x64" means our parser interprets the code as targeting an x64 platform (not ARM). Yeah, we could query the ARM compiler for defines/includes, but our parser has internal defines and stuff, so there would be some incorrect state probably.

[davidwin]

I managed to get the crash on a different install of VSCode by doing this in an empty folder (WSL Remote mode):

• Create a file, a.cpp, with contents:

  #include "a.h"

• Create another file, a.h, with contents:

  #include "a.h"
  int SomeGlobalSymbol;

• Switch between the files, make some edits, save and hover over parts of the source, and you will get the crash.
• Try to complete Some in a.cpp and notice that you don't get any suggestions. There is also no sguiggly under the #include in a.cpp, but there is in a.h.
• Change a.h to:

  #include "notfound.h"
  int SomeGlobalSymbol;

• Saving, hovering etc will not cause a crash.
• Notice that you can complete Some in a.cpp, although there is an error in the program. The #include "a.h" in a.cpp has a red squiggly now.

I hope that these steps demonstrate that a recursive include causes a different kind of error state than a missing include, which doesn't seem right.

Great to see that you're considering a proper ARM IntelliSense mode! You might want to look into supporting --sysroot properly (in compile_commands.json) in that case, since ARM projects are probably more likely to be cross compiled, at least in WSL/Windows mode.

Update: I tried this in plain Windows mode, and it worked/failed identically.

[sean-mcmanus]

If you see the "No IL available" that isn't a crash (although there would still be no IntelliSense, as described). A crash would show a message like "Failed to read response from server" or "Connection to server got closed.".

We're tracking handling sysroot in compile commands at https://github.com/microsoft/vscode-cpptools/issues/1575 . One potential workaround is to add it to compilerArgs.

[davidwin]

Yes, "crash" was the wrong choice of words here, but it does seem like the compiler fails to recover in a way that at least leaves some IntelliSense working in the editor. I can see the problem, because it can't simply back out when a file includes itself only once, or even "a lot" of times, or when several headers form a (finite) cycle in order to play some evil preprocessor trick. But, beyond some limit, perhaps the compiler should just restart and not allow any cycles, and instead try to recover as some information as possible? It's a bit surprising at first that the effect of an include cycle is so different from a missing include.

As for --sysroot, I'm currently doing just that and post-process the compile_commands.json file to extract that flag to compilerArgs.

[boardkeystown]

yeah nothing I can do seems to get VSCode C/C++ intilisense to work on the raspberry pi....

[bobbrow]

I think the issues described in this issue are addressed in version 1.2.0 of the extension which is currently in preview. If you set the C_Cpp.updateChannel setting to "Insiders", you can try it out and let us know. We'll mark this as "fixed (release pending)" unless we hear otherwise. Thanks!