Vscode-cpptools: No intellisense in 1.0.0

Created on 15 Sep 2020  路  15Comments  路  Source: microsoft/vscode-cpptools

Type: General
Since switching to 1.0.0, I'm no longer getting any intellisense. I was also having this problem with the last set of insiders builds (I think since 2 or 3?), so I have been using 0.29.0. Since the upgrade, this is what I'm seeing in the C/C++ extension output:

Warning: Database safety check failed. Recreating database.
[rc=0x80004005] (DB: false, Expected: true)
Quick info operation failed: FE: 'Compiler exited with error - No IL available'
Quick info operation failed: FE: 'Compiler exited with error - No IL available'
  • OS and Version: Windows 10
  • VS Code Version: 1.49.0
  • C/C++ Extension Version: 1.0.0

I'm using GCC on windows via MSYS2 (gcc version 10.2.0 (Rev1, Built by MSYS2 project)).

If I create a new basic project with a similar config as below, everything seems to work fine, but with my game engine project, which uses a PCH (forcedInclude), 2 main build targets, and 3 libraries built alongside them, I get no intellisense whatesoever (not even from main). This is my what my Win32 configuration looks like:

{
    "name": "Win32",
    "intelliSenseMode": "gcc-x64",
    "compilerPath": "C:/msys64/mingw64/bin/g++.exe",
    "includePath": [
        "${workspaceFolder}/include",
        "${workspaceFolder}/src/main",
        "${workspaceFolder}/src/cruise",
        "${workspaceFolder}/vendor/catch2/single_include",
        "${workspaceFolder}/vendor/entt/src",
        "${workspaceFolder}/vendor/fmt/include",
        "${workspaceFolder}/vendor/ghc_fs/include",
        "${workspaceFolder}/vendor/glfw/include",
        "${workspaceFolder}/vendor/glm",
        "${workspaceFolder}/vendor/imgui",
        "${workspaceFolder}/vendor/nlohmann_json/single_include",
        "${workspaceFolder}/vendor",
        "${workspaceFolder}/test"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE"
    ],
    "cStandard": "c11",
    "cppStandard": "c++20",
    "forcedInclude": [
        "${workspaceFolder}/src/main/PCH.hpp"
    ]
}

User:


    "C_Cpp.autocomplete": "Default",
    "C_Cpp.intelliSenseEngine": "Default",
    "C_Cpp.preferredPathSeparator": "Forward Slash",
    "C_Cpp.workspaceParsingPriority": "highest",
    "C_Cpp.intelliSenseCachePath": "~/.vscode/cpptools-cache",
    "C_Cpp.autoAddFileAssociations": false,
    "C_Cpp.vcpkg.enabled": false,

Workspace:

    "C_Cpp.autocomplete": "Default",
    "C_Cpp.intelliSenseEngine": "Default",
    "C_Cpp.dimInactiveRegions": false,
    "C_Cpp.preferredPathSeparator": "Forward Slash",
    "C_Cpp.loggingLevel": "Warning",
    "C_Cpp.workspaceParsingPriority": "highest",
    "C_Cpp.enhancedColorization": "Disabled",
Language Service bug fixed (release pending) parser

Most helpful comment

We have a fix for this issue and are hoping to release it today. Thanks for the help in identifying the case.

All 15 comments

Can you follow the instructions in my comment in #6114 and let us know how that goes?

https://github.com/microsoft/vscode-cpptools/issues/6114#issuecomment-692863114

Also of note, I'm using bash as the terminal, so paths uses forward slashes.

"terminal.integrated.shell.windows": "C:/Program Files/Git/bin/bash.exe"

This is the actual command that gets run (builds):

g++.exe -MT bin/Debug/obj/src/main/Main.cpp.o -MMD -MP -MF bin/Debug/dep/src/main/Main.cpp.Td -Og -g3 -std=c++20 -Wall -Wextra -Werror -Wpedantic -pedantic-errors -Wshadow -Wundef -Wunreachable-code -Wunused -Wnoexcept -Winit-self -Wcast-align -Wdouble-promotion -Wformat=2 -Wmissing-declarations -Wmissing-include-dirs -Wredundant-decls -Wodr -Winvalid-pch -D_DEBUG -IC:/msys64/mingw64/include/ -Ivendor/catch2/single_include/ -Ivendor/entt/src/ -Ivendor/fmt/include/ -Ivendor/ghc_fs/include/ -Ivendor/glfw/include/ -Ivendor/glm/ -Ivendor/imgui/ -Ivendor/nlohmann_json/single_include/ -Ivendor/ -Iinclude/ -Isrc/main/  -include bin/Debug/obj/src/main/PCH.hpp -o bin/Debug/obj/src/main/Main.cpp.o -c src/main/Main.cpp && mv -f bin/Debug/dep/src/main/Main.cpp.Td bin/Debug/dep/src/main/Main.cpp.d && touch bin/Debug/obj/src/main/Main.cpp.o

The includes in c_cpp_properties.json are more all-purpose, since the projects contains multiple build targets, but they shouldn't adversely affect the intellisense.

Per instructed in #6114, this is the command (with custom -o & -c):

g++.exe -std=c++20 -IC:\USERS\REW\CPP\CRUISE-ENGINE\INCLUDE -IC:\USERS\REW\CPP\CRUISE-ENGINE\SRC\MAIN -IC:\USERS\REW\CPP\CRUISE-ENGINE\SRC\CRUISE -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\CATCH2\SINGLE_INCLUDE -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\ENTT\SRC -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\FMT\INCLUDE -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\GHC_FS\INCLUDE -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\GLFW\INCLUDE -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\GLM -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\IMGUI -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR\NLOHMANN_JSON\SINGLE_INCLUDE -IC:\USERS\REW\CPP\CRUISE-ENGINE\VENDOR -IC:\USERS\REW\CPP\CRUISE-ENGINE\TEST -IC:\MSYS64\MINGW64\INCLUDE\C++\10.2.0 -IC:\MSYS64\MINGW64\INCLUDE\C++\10.2.0\X86_64-W64-MINGW32 -IC:\MSYS64\MINGW64\INCLUDE\C++\10.2.0\BACKWARD -IC:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\10.2.0\INCLUDE -IC:\MSYS64\MINGW64\INCLUDE -IC:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\10.2.0\INCLUDE-FIXED -IC:\MSYS64\MINGW64\X86_64-W64-MINGW32\INCLUDE -IC:\MINGW64\INCLUDE -D_WIN32 -D_DEBUG -DUNICODE -D_UNICODE -include C:\USERS\REW\CPP\CRUISE-ENGINE\SRC\MAIN\PCH.HPP -o C:\USERS\REW\CPP\CRUISE-ENGINE\BIN\DEBUG\testing_Main.cpp.o -c C:\USERS\REW\CPP\CRUISE-ENGINE\SRC\MAIN\Main.cpp

With bash as the terminal & due to backslashes, this yields:

g++.exe: error: C:USERSREWSFMLCRUISE-ENGINE2SRCMAINMain.cpp: No such file or directory
g++.exe: fatal error: no input files
compilation terminated.

Using the default terminal, the object file built correctly.

One thing that's weird is that "C:\MINGW64\INCLUDE" got added somewhere based on that Log Diagnostics command. That is actually a separate compiler in my case. (mingw 7.3.0 64-bit). Again though, I have a boilerplate project with almost the identical setup (same compiler paths, less includes), and it works. Log diagnostics added the same path in that case.

In #6114 it sounds like we narrowed this down (or at least one cause of it) to the configuration resulting in an #error directive being processed which is tripping up the language server.

@andrew-r-king did you do your test compile with all the paths in the Log Diagnostics output? (including the wrong one) We should figure out why you're getting an incorrect system include path. [tagging @Colengms - did we update the compiler logging to see if something is failing there?]

Yes, the compile command included the incorrect path. It was at least last in the list, so I think that's maybe why it didn't have any conflicts.

I looked at #6114 and tried the #error test in the working boilerplate project, but still got intellisense in that case.

It happens if you add the code below into your code.

pragma push_macro("__has_builtin")

pragma pop_macro("__has_builtin")

define A __has_builtin(0);

A;

We have a fix for the #error issue and I also just verified that @MiyaMorg's example is fixed by the same changeset. When we have an insiders build for the patch ready, we will let you know. Thanks everyone for your help getting to the bottom of this!

I'm going to have to go back on my statement about @MiyaMorg's example. It worked when I tested the change with a debug build, but there's some optimization bug in the compiler when we build for release that caused the fix not to work for that case. We'll need to continue to investigate that. The #error issue is fixed in both build variants.

We published an insiders release with the fix for the #error issue. We're still investigating the code sample in this issue.
https://github.com/microsoft/vscode-cpptools/releases/tag/1.0.1-insiders

Just tried it. It looks like the #error fix didn't address my issue... still seeing a bunch of "Quick info operation failed: FE: 'Compiler exited with error - No IL available'" in the output. I'm hoping it's that __has_builtin example above, but I'm not too sure. I have to dig through the headers I'm using (including 3rd party libraries) and track it down.

It's 100% the code sample MiyaMorg shared. For me, that pragma was inside psdk_inc/intrin-impl.h, from a combination of #include <winuser.h> and #include <nlohmann/json.hpp> (json lib)

#include <iostream>

#include <psdk_inc/intrin-impl.h>
// #pragma push_macro("__has_builtin")
// #pragma pop_macro("__has_builtin")

#define BUILTIN(expr) __has_builtin(expr)

int main()
{
    std::cout << "Testing...";
    #if BUILTIN(0)
    std:: // (nothing)
    #endif

    return 0;
}

We have a fix for this issue and are hoping to release it today. Thanks for the help in identifying the case.

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.0.1 . Let us know if you encounter other "No IL" issues. We know of at least one other regression we're still working on: https://github.com/microsoft/vscode-cpptools/issues/6166 .

The new version works great. Thanks for figuring it out!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

igorPhelype picture igorPhelype  路  3Comments

jheinzel picture jheinzel  路  3Comments

montery8 picture montery8  路  3Comments

arl picture arl  路  3Comments

jrieken picture jrieken  路  3Comments