michelleangela
commented
4 years ago Can you enable logging of the language server and share the logs?
Closed mxsrv closed 3 years ago
michelleangela
commented
4 years ago Can you enable logging of the language server and share the logs?
mxsrv
commented
4 years ago I'm sorry that the logs are in german. Is it possible to change the language?
michelleangela
commented
4 years ago @mxsrv The C/C++ extension follows the display language used on VS Code. You can change the display language of VS Code by following instructions at https://code.visualstudio.com/docs/getstarted/locales.
wapjoe
commented
4 years ago Hello,
i have the same problems with user-defined libs in the respective includePath of projects. I'm using VSC in conjunction with Platformio and the bug only occurs since C/C++ version 0.26.2.
After testing some things, I downgraded to 0.26.1 and after a restart, the error didn't occur. A new update to 0.26.2 caused the error again. I put a .h file under /include in the project and it makes no difference if I include the file with #include "fram.h" or with #include
These 2 errors always appear when starting VSC if /src/main.cpp was open during the last session:
The error messages were translated by a translator from German into English and may not contain the correct wording. Here are the original messages:
If the file was not open and is opened afterwards, the error does not occur. As mentioned before, it does not happen with version 0.26.1. If you need more information, please let us know.
Many greetings wapjoe
michelleangela
commented
4 years ago @wapjoe Can you run C/C++: Log diagnostics and share the logs with version 0.26.2?
wapjoe
commented
4 years ago @michelleangela Log diagnostics without error (file not open): -------- Diagnostics - 10.12.2019, 21:23:48 Version: 0.26.2 Current Configuration: { "name": "Win32", "includePath": [ "c:/OneDrive/Projekte/PlatformIO/Projects/Display XPT2046/include", "c:/OneDrive/Projekte/PlatformIO/Projects/Display XPT2046/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SPI/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/cores/arduino", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/variants/eightanaloginputs", "C:/Users/wapjoe/.platformio/lib/Adafruit FRAM I2C_ID658", "C:/Users/wapjoe/.platformio/lib/DHTlib_ID1336", "C:/Users/wapjoe/.platformio/lib/RunningMedian_ID1361", "C:/Users/wapjoe/.platformio/lib/SFFS_ID2037", "C:/Users/wapjoe/.platformio/lib/Ticker_ID1586", "C:/Users/wapjoe/.platformio/lib/Time_ID44", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/EEPROM/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/HID/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SoftwareSerial/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/Wire/src", "C:/Users/wapjoe/.platformio/packages/tool-unity" ], "browse": { "limitSymbolsToIncludedHeaders": true, "path": [ "c:/OneDrive/Projekte/PlatformIO/Projects/Display XPT2046/include", "c:/OneDrive/Projekte/PlatformIO/Projects/Display XPT2046/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SPI/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/cores/arduino", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/variants/eightanaloginputs", "C:/Users/wapjoe/.platformio/lib/Adafruit FRAM I2C_ID658", "C:/Users/wapjoe/.platformio/lib/DHTlib_ID1336", "C:/Users/wapjoe/.platformio/lib/RunningMedian_ID1361", "C:/Users/wapjoe/.platformio/lib/SFFS_ID2037", "C:/Users/wapjoe/.platformio/lib/Ticker_ID1586", "C:/Users/wapjoe/.platformio/lib/Time_ID44", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/EEPROM/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/HID/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SoftwareSerial/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/Wire/src", "C:/Users/wapjoe/.platformio/packages/tool-unity" ] }, "defines": [ "PLATFORMIO=40100", "ARDUINO_AVR_NANO", "F_CPU=16000000L", "ARDUINO_ARCH_AVR", "ARDUINO=10808", "__AVR_ATmega328P__" ], "intelliSenseMode": "clang-x64", "cStandard": "c11", "cppStandard": "c++11", "compilerPath": "C:/Users/wapjoe/.platformio/packages/toolchain-atmelavr/bin/avr-gcc.exe", "compilerArgs": [ "-mmcu=atmega328p" ] } No active translation units.
Log diagnosis with error (file opened): -------- Diagnostics - 10.12.2019, 21:25:23 Version: 0.26.2 Current Configuration: { "name": "Win32", "includePath": [ "c:/OneDrive/Projekte/PlatformIO/Projects/Ergometer ProMini 1.0/include", "c:/OneDrive/Projekte/PlatformIO/Projects/Ergometer ProMini 1.0/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/Wire/src", "C:/Users/wapjoe/.platformio/lib/Ticker_ID1586", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SoftwareSerial/src", "C:/Users/wapjoe/.platformio/lib/RunningMedian_ID1361", "C:/Users/wapjoe/.platformio/lib/DHTlib_ID1336", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/cores/arduino", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/variants/eightanaloginputs", "C:/Users/wapjoe/.platformio/lib/Adafruit FRAM I2C_ID658", "C:/Users/wapjoe/.platformio/lib/SFFS_ID2037", "C:/Users/wapjoe/.platformio/lib/Time_ID44", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/EEPROM/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/HID/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SPI/src", "C:/Users/wapjoe/.platformio/packages/tool-unity" ], "browse": { "limitSymbolsToIncludedHeaders": true, "path": [ "c:/OneDrive/Projekte/PlatformIO/Projects/Ergometer ProMini 1.0/include", "c:/OneDrive/Projekte/PlatformIO/Projects/Ergometer ProMini 1.0/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/Wire/src", "C:/Users/wapjoe/.platformio/lib/Ticker_ID1586", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SoftwareSerial/src", "C:/Users/wapjoe/.platformio/lib/RunningMedian_ID1361", "C:/Users/wapjoe/.platformio/lib/DHTlib_ID1336", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/cores/arduino", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/variants/eightanaloginputs", "C:/Users/wapjoe/.platformio/lib/Adafruit FRAM I2C_ID658", "C:/Users/wapjoe/.platformio/lib/SFFS_ID2037", "C:/Users/wapjoe/.platformio/lib/Time_ID44", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/EEPROM/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/HID/src", "C:/Users/wapjoe/.platformio/packages/framework-arduino-avr/libraries/SPI/src", "C:/Users/wapjoe/.platformio/packages/tool-unity" ] }, "defines": [ "PLATFORMIO=40100", "ARDUINO_AVR_PRO", "F_CPU=16000000L", "ARDUINO_ARCH_AVR", "ARDUINO=10808", "AVR_ATmega328P__" ], "intelliSenseMode": "clang-x64", "cStandard": "c11", "cppStandard": "c++11", "compilerPath": "C:/Users/wapjoe/.platformio/packages/toolchain-atmelavr/bin/avr-gcc.exe", "compilerArgs": [ "-mmcu=atmega328p" ] } Translation Unit Mappings: [ C:\OneDrive\Projekte\PlatformIO\Projects\Ergometer ProMini 1.0\src\main.cpp ]: C:\ONEDRIVE\PROJEKTE\PLATFORMIO\PROJECTS\ERGOMETER PROMINI 1.0\SRC\MAIN.CPP Translation Unit Configurations: [ C:\OneDrive\Projekte\PlatformIO\Projects\Ergometer ProMini 1.0\src\main.cpp ]: Process ID: 19720 Memory Usage: 19 MB Compiler Path: C:/Users/wapjoe/.platformio/packages/toolchain-atmelavr/bin/avr-gcc.exe Includes: C:\ONEDRIVE\PROJEKTE\PLATFORMIO\PROJECTS\ERGOMETER PROMINI 1.0\INCLUDE C:\ONEDRIVE\PROJEKTE\PLATFORMIO\PROJECTS\ERGOMETER PROMINI 1.0\SRC C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\FRAMEWORK-ARDUINO-AVR\LIBRARIES\WIRE\SRC C:\USERS\WAPJOE.PLATFORMIO\LIB\TICKER_ID1586 C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\FRAMEWORK-ARDUINO-AVR\LIBRARIES\SOFTWARESERIAL\SRC C:\USERS\WAPJOE.PLATFORMIO\LIB\RUNNINGMEDIAN_ID1361 C:\USERS\WAPJOE.PLATFORMIO\LIB\DHTLIB_ID1336 C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\FRAMEWORK-ARDUINO-AVR\CORES\ARDUINO C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\FRAMEWORK-ARDUINO-AVR\VARIANTS\EIGHTANALOGINPUTS C:\USERS\WAPJOE.PLATFORMIO\LIB\ADAFRUIT FRAM I2C_ID658 C:\USERS\WAPJOE.PLATFORMIO\LIB\SFFS_ID2037 C:\USERS\WAPJOE.PLATFORMIO\LIB\TIME_ID44 C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\FRAMEWORK-ARDUINO-AVR\LIBRARIES\EEPROM\SRC C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\FRAMEWORK-ARDUINO-AVR\LIBRARIES\HID\SRC C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\FRAMEWORK-ARDUINO-AVR\LIBRARIES\SPI\SRC C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\TOOL-UNITY C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\TOOLCHAIN-ATMELAVR\LIB\GCC\AVR\5.4.0\INCLUDE C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\TOOLCHAIN-ATMELAVR\LIB\GCC\AVR\5.4.0\INCLUDE-FIXED C:\USERS\WAPJOE.PLATFORMIO\PACKAGES\TOOLCHAIN-ATMELAVR\AVR\INCLUDE Defines: PLATFORMIO=40100 ARDUINO_AVR_PRO F_CPU=16000000L ARDUINO_ARCH_AVR ARDUINO=10808 AVR_ATmega328P__ Standard Version: c++11 IntelliSense Mode: gcc-x64 Other Flags: --g++ --gnu_version=50400 Total Memory Usage: 19 MB
wapjoe
commented
4 years ago @michelleangela Further note:
In the configuration (Edit "includePath" settings) the compiler path is not found (No compiler paths detected), so I cannot change the IntelliSense mode:
michelleangela
commented
4 years ago @wapjoe
Your c_cpp_properties.json looks okay. The compiler path setting on the configuration UI editor should display your specified C:/Users/wapjoe/.platformio/packages/toolchain-atmelavr/bin/avr-gcc.exe. The message (no compiler path found) is intended to indicate that the language server was not able to find any default compilers on your machine, but it the UI should not disable the input field for custom paths (I created separate issue for that). You can modify the compiler path directly in the c_cpp_properties.json file.
As for the #include error, does the squiggles go away when you close and reopen the source file without closing VS Code?
Can you also provide English logs from the language server?
To change the display language of VS Code, follow instructions at https://code.visualstudio.com/docs/getstarted/locales.
wapjoe
commented
4 years ago @michelleangela thx for your help If I close the file immediately after starting it and open it again via the Explorer workspace, the error is gone. If I first click on the file via the Explorer workspace and close it, the error persists and does also not disappear after reopening it.
Here the logfile, I hope it was right, seems to be very long:
sean-mcmanus
commented
4 years ago Your log file doesn't show any missing include error message. Can you provide a log file that repros the bug? Do you see a includePath missing in the logging that corresponds to the missing include error?
wapjoe
commented
4 years ago What have I done wrong? After the instructions I set the logging level to debug, in the output panel I set C/C++. In the output appears "Update IntelliSense time (sec): 1.156". When I set the Log Filter to one of the projects (C/C**: ....) with the Include error and open the main.cpp, it appears:
cpptools/getCodeActions: 38
textDocument/didOpen
Checking for syntax errors: file:///c%3A/OneDrive/Projekte/PlatformIO/Projects/Ergometer%20ProMini%201.0/src/main.cpp
Queueing IntelliSense update for files in translation unit of: C:\ONEDRIVE\PROJEKTE\PLATFORMIO\PROJECTS\ERGOMETER PROMINI 1.0\SRC\MAIN.CPP
cpptools/activeDocumentChange
cpptools/textEditorSelectionChange
cpptools/getDocumentSymbols: 39
cpptools/textEditorSelectionChange
cpptools/getDocumentSymbols
idle loop: reparsing the active document
Checking for syntax errors: file:///c%3A/OneDrive/Projekte/PlatformIO/Projects/Ergometer%20ProMini%201.0/src/main.cpp
Queueing IntelliSense update for files in translation unit of: C:\ONEDRIVE\PROJEKTE\PLATFORMIO\PROJECTS\ERGOMETER PROMINI 1.0\SRC\MAIN.CPP
cpptools/getCodeActions: 40
Error squiggle count: 0
Error squiggle count: 0However, the error does not occur during subsequent opening. When restarting VSC, with the opened file, the output panel first starts with the filter "tasks", when I switch back to "C/C**: ..." this log appears and the include error is still displayed in the program:
michelleangela
commented
4 years ago The logs show there are no error squiggles and yet squiggles are displayed for #include.
Are you using multiroot, that is more than one project in a VS Code workspace? If so, the logging that displayed/selected with currently opened file could be for a different project, and to better isolate the issue, only open one project to ensure the correct log is displayed/selected.
wapjoe
commented
4 years ago Ah, you mean just one project per workspace? I will test tomorrow (European Time) and give feedback.
michelleangela
commented
4 years ago Ah, you mean just one project per workspace? I will test tomorrow (European Time) and give feedback.
Yes, one project per workspace. There are currently some IntelliSense issues when trying to work with multiple projects in one workspace. This could be a new issue.
wapjoe
commented
4 years ago Okay, I'll try it tomorrow and report on it. :-)
Colengms
commented
4 years ago Hi @wapjoe . In the log output, it mentions: "Error squiggle count: 0". For the scenario in which you are seeing the error squiggle, you should see a squiggle count > 0.
The "update your includepath" error comes from the IntelliSense process. The output from C/C++: Log Diagnostics tells us exactly what arguments we passed to the IntelliSense process. The main C/C++ log output (when log level is set) should tell us of the events leading up to passing those arguments to the IntelliSense process.
wapjoe
commented
4 years ago Hi @Colengms the error that's been reported to me is apparently a false error. Why the error is not recorded in any diagnosis and log files, I cannot say.
wapjoe
commented
4 years ago Hello @michelleangela I have now created a new workspace and added only one project, source code and lib in the include folder are copied from the old project.
When starting with main.cpp still open, no error is displayed anymore, so I don't think the debug output is needed and probably didn't output anything else than before?
Too many projects have accumulated in my old workspace over the years, so I wanted to clean it up anyway. ;-) So I will add more projects to the workspace and test the behavior. If there are already problems with a few projects, I will temporarily change to version 0.26.1, but I'm happy to be available for further tests.
The result, from how many projects it comes to the error, I write later still.
Thanks for your support so far!
Update!
If I create a new workspace and integrate my projects in small steps (5 each) (add folders to workspace, not as new projects) and restart VSC, there is no error with all 22 projects. However, if I remove all the folders and insert the 22 project folders at once, the include error will occur the next time VSC restarts.
2nd update...
The solution only works if the project with the include error is inserted first. For example, if 1 or more project(s) are added without the error and the problematic project is added to Wordplace after that, the include error will reappear when restarting with main.cpp open.
Very strange and I can't explain it...
jxramos
commented
4 years ago I'm seeing the same #include errors detected. Please update your includePath but it appears confined to system includes. I'm on a MacOS.
MACOS
10.14.6 (18G1012)
VSCODE
Version: 1.40.2
Commit: f359dd69833dd8800b54d458f6d37ab7c78df520
Date: 2019-11-25T14:52:45.129Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Darwin x64 18.7.0@wapjoe I created a new issue #4731 for adding multiple projects to a workspace.
wapjoe
commented
4 years ago @wapjoe I created a new issue #4731 for adding multiple projects to a workspace.
Thank you!
michelleangela
commented
4 years ago @jxramos It could be that the language server is unable to query the compiler for the system include paths.
Can you provide the following additional info to help us further investigate:
C/C++: log diagnosticsjxramos
commented
4 years ago @michelleangela how can I test whether or not I have multiple projects in a workspace? Is that to say I open VSCode on some folder /dirA and and some later point open VSCode to /dirA/dirB. I'm not even sure I use workspaces, I always open to a folder and then use the Open Recent menu item.
I'm not sure how to engage the log from running first bullet point item. The second item I'm assuming you're referring to enabling the logging for the language server bit from the documentation? https://code.visualstudio.com/docs/cpp/enable-logging-cpp#_enable-logging-for-the-language-server
jxramos
commented
4 years ago Here's some more details, when I invoke Go to Definition
I find several hits resolved on the include path.
michelleangela
commented
4 years ago @jxramos
A workspace with more than one project is opening VSCode on some folder /dirA and then adding another folder /dirB via "Add Folder to Workspace..."
In your case, it sounds like you're only opening one folder.
The command C/C++: Log diagnostics can be executed through the VS Code command palette. Prior to executing the command. first open the source file that reproduces the issue and then run the command.
For the second logging (that logs info about what's happening with the language server) follow "enable the logging for the language server" https://code.visualstudio.com/docs/cpp/enable-logging-cpp#_enable-logging-for-the-language-server.
jxramos
commented
4 years ago Here's the logs as rendered...
-------- Diagnostics - 12/11/2019, 1:59:06 PM
Version: 0.26.2
Current Configuration:
{
"name": "Mac",
"macFrameworkPath": [
"/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks"
],
"intelliSenseMode": "clang-x64",
"includePath": [
"/Users/USERX/WORKDIR/linux/usr/include",
"/Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu",
"/Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu/c++/6.5.0",
"/Users/USERX/WORKDIR/linux/usr/include/clang/4.0.1/include",
"${workspaceFolder}/base",
"${workspaceFolder}"
],
"defines": [
"linux"
],
"compilerPath": "/usr/bin/clang",
"compilerArgs": [],
"cStandard": "c11",
"cppStandard": "c++11",
"browse": {
"path": [
"/Users/USERX/WORKDIR/linux/usr/include",
"/Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu",
"/Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu/c++/6.5.0",
"/Users/USERX/WORKDIR/linux/usr/include/clang/4.0.1/include",
"${workspaceFolder}/base",
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true
}
}
Translation Unit Mappings:
[ /Users/USERX/WORKDIR/PROJ/main.cpp ]:
/Users/USERX/WORKDIR/PROJ/main.cpp
Translation Unit Configurations:
[ /Users/USERX/WORKDIR/PROJ/main.cpp ]:
Process ID: 51409
Memory Usage: 16 MB
Compiler Path: /usr/bin/clang
Includes:
/Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu
/Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu/c++/6.5.0
/Users/USERX/WORKDIR/linux/usr/include/clang/4.0.1/include
/Users/USERX/WORKDIR/PROJ/base
/Users/USERX/WORKDIR/PROJ
/Users/USERX/WORKDIR/linux/usr/include
Frameworks:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
Defines:
linux
Standard Version: c++11
IntelliSense Mode: clang-x64
Other Flags:
--clang
--clang_version=100001
Total Memory Usage: 16 MBAnd here's the
Some of the bits of possible interest...
Attempting to get defaults from compiler found on the machine: '/usr/bin/clang'
terminating child process: 51515
cpptools/queryCompilerDefaults: 1
Attempting to get defaults from compiler found on the machine: '/usr/bin/clang'
terminating child process: 51518
textDocument/didOpen
cpptools/getCodeActions: 2
cpptools/getDocumentSymbols: 3
cpptools/didChangeFolderSettings
Code browsing service initialized
Attempting to get defaults from compiler in "compilerPath" property: '/usr/bin/clang'
terminating child process: 51522
Shutting down IntelliSense server: /Users/USERX/WORKDIR/PROJ/main.cpp
terminating child process: 51533
still alive, killing...
not exited yet. Will sleep for 10 milliseconds and try again.
Closing the communication channel.
IntelliSense client creation aborted: /Users/USERX/WORKDIR/PROJ/main.cpp
sending compilation args for /Users/USERX/WORKDIR/PROJ/main.cpp
include: /Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu
include: /Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu/c++/6.5.0
include: /Users/USERX/WORKDIR/linux/usr/include/clang/4.0.1/include
include: /Users/USERX/WORKDIR/PROJ/base
include: /Users/USERX/WORKDIR/PROJ
include: /Users/USERX/WORKDIR/linux/usr/include
Queueing IntelliSense update for files in translation unit of: /Users/USERX/WORKDIR/PROJ/main.cpp
Error squiggle count: 87
Error squiggles will be disabled in: file:///Users/USERX/WORKDIR/PROJ/main.cpp
terminating child process: 51539@michelleangela, just as a good tip for git hub issue readability it may be better to post the language server log as a file attachment. Mine was incredibly long. Should be a good recommendation for the vscode staff to request comments with that information be uploaded as such. That is until github implements some scrollable code block that enters scrollmode after some 200 lines or whatever the threshold is.
Colengms
commented
4 years ago Hi @jxramos .
Could you check for additional details on the error squiggles? They may be referring to something being included deeper in the hierarchy of includes.
The logs indicate that we're able to get system includes from clang, and we're providing them to the intelliSense process. It looks like they are under: /Users/USERX/WORKDIR/linux/usr/include
Are Linux gcc headers expected to work on Mac?
jxramos
commented
4 years ago There are some linux specific variants for sure resolvable on my imports folders, maybe I have the order mixed up?Just double checked includePath does have my systemIncludePath as the first element. As further background I basically tarred up /usr/include folder on my linux desktop and copied the file to my mac to do my code studies from my mac for development that is otherwise in a linux environment.
The immediate children to my systemIncludePath are the following files...
memory.h.txt
features.h.txt
And cross referencing to a gnu c library mirror on GitHub it appears to be this version of the file: https://github.com/lattera/glibc/blob/master/string/memory.h Nothing really stands out as linux specific in that file, it appears to be a bunch of gnu-C definitions.
I'm assuming clang uses the /usr/include folder on linux to resolve system includes, maybe I'm off there though.
Could it be that the language server needs to properly evaluate all header possibilities? So maybe even though the one in my systemIncludePath is legit presumably another in the includePaths is not and breaks things?
Colengms
commented
4 years ago Hi @jxramos . Right after "sending compilation args for" in the language server logs, it lists the includes and defines we passed to the IntelliSense process. Since there are a bunch of compiler-specific defines there, it looks like the compiler is being interrogated successfully. However, the only headers listed are:
include: /Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu
include: /Users/USERX/WORKDIR/linux/usr/include/x86_64-linux-gnu/c++/6.5.0
include: /Users/USERX/WORKDIR/linux/usr/include/clang/4.0.1/include
include: /Users/USERX/WORKDIR/PROJ/base
include: /Users/USERX/WORKDIR/PROJ
include: /Users/USERX/WORKDIR/linux/usr/include
framework: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/FrameworksI had assumed based on the x86_64-linux-gnu that these paths were provided by the compiler, but they look to be only your user includes (and framework).
Could you try running clang with the following argments?
/usr/bin/clang -Wp,-v -E -dD -xc++ -m64 /dev/nullThat's the command we're sending to clang to detect system includes and defines. Look for the list of system includes. If there are some there and we're not picking them up, could you copy the output to a file and post it here?
jxramos
commented
4 years ago Beautiful stuff, if that's the case it does indeed appear the compiler isn't looking in the expected system include path according to my VSCode settings. It's looking at these paths instead...
clang -cc1 version 10.0.1 (clang-1001.0.46.4) default target x86_64-apple-darwin18.7.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Library/Developer/CommandLineTools/usr/include/c++/v1
/Library/Developer/CommandLineTools/usr/lib/clang/10.0.1/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (framework directory)
End of search list.
full console output at clang_check.txt
If I probe my MacOS System Includes I get the following hits (system_include_hits.txt) from running this script below.
echo =================================================== > system_include_hits.txt
echo find /usr/local/include >> system_include_hits.txt
find /usr/local/include >> system_include_hits.txt
echo =================================================== >> system_include_hits.txt
echo find /Library/Developer/CommandLineTools/usr/include/c++/v1 >> system_include_hits.txt
find /Library/Developer/CommandLineTools/usr/include/c++/v1 >> system_include_hits.txt
echo =================================================== >> system_include_hits.txt
echo find /Library/Developer/CommandLineTools/usr/lib/clang/10.0.1/include >> system_include_hits.txt
find /Library/Developer/CommandLineTools/usr/lib/clang/10.0.1/include >> system_include_hits.txt
echo =================================================== >> system_include_hits.txt
echo find /Library/Developer/CommandLineTools/usr/include >> system_include_hits.txt
find /Library/Developer/CommandLineTools/usr/include >> system_include_hits.txt
echo =================================================== >> system_include_hits.txt
echo find /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include >> system_include_hits.txt
find /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include >> system_include_hits.txt
echo =================================================== >> system_include_hits.txt
echo "find /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (framework directory)" >> system_include_hits.txt
find "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks" >> system_include_hits.txtTracing the memory example there is one path it should resolve at...
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/memory.hAll it does is import string...
/*
* Copyright (c) 1988, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)memory.h 8.1 (Berkeley) 6/2/93
*/
#include <string.h>String itself appears safe too, there's a few hits actually.
/Library/Developer/CommandLineTools/usr/include/c++/v1/string.h
/Library/Developer/CommandLineTools/usr/include/c++/v1/string.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/string.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/string.hPretty mysterious. Either way just wondering if the correct behavior would be to pass on the value of C_Cpp.default.systemIncludePath to the following clang option: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-isysroot-dir. There's other options too like adding a dir to the system includes https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-cxx-isystem-directory.
This is all very interesting, there's like overlapping tools coordinated together to give us the VSCode C++ experience. Some subset of those tools are happy with the information I provide, but the language server tool is not happy somehow. Am I reading things right?
Colengms
commented
4 years ago @jxramos ,
The C/C++ Extension (this repo) doesn't actually build or compile. We only invoke the compiler for the purpose of querying it for system includes and defines, which we pass along to a separate process which parses (first-pass compiles) the code to generate IntelliSense information.
All of the paths you see after "#include <...> search starts here:" should be passed along to the IntelliSense process. However, I don't see these being passed to it:
/usr/local/include
/Library/Developer/CommandLineTools/usr/include/c++/v1
/Library/Developer/CommandLineTools/usr/lib/clang/10.0.1/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/includeWe do confirm that paths exist before using them. Are these paths present on your system?
jxramos
commented
4 years ago They're certainly present, the system_include_hits.txt file I attached above is the console output from running the find command at the terminal on each of the directories enumerated by the clang command you provided. That's what that script snippet above was meant to convey. There's a bunch of files hit in that text file too, including the ones I was expecting to be resolved by intellisense.
jxramos
commented
4 years ago I wonder if the process is being blocked by some security permissions or something of the like preventing it from observing the protected folders given to it.
jxramos
commented
4 years ago Following the light bulb icon to the left of the error where I chose one of the includes that would resolve the header at random made the squiggly's go away. The side effect appears to have defined a c_cpp_properties file. There may be a gap then between intellisense ignoring my VSCode level main settings and only consulting those defined in the c_cpp_properties file alone or partially or something. The light bulb workflow
definitely populated a cpp properties config... .vscode/c_cpp_properties.json
{
"configurations": [
{
"name": "Mac",
"macFrameworkPath": [
"/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks"
],
"intelliSenseMode": "clang-x64",
"includePath": [
"${default}",
"/Users/USERX/WORKDIR/linux/usr/include/c++/4.8"
]
}
],
"version": 4
}I had previously not encountered this particular configuration page which has the extensions icon present. I always just edit the file ~/Library/Application Support/Code/User/settings.json so my changes are global for all the folders I work on.
There may be some strange absolute path issue or the fact the Application Support has a space in it. When I open my settings.json file and right click its tab to Copy path it gives me:
~/Library/Application Support/Code/User/settings.json
But the path preview in the VSCode editor displays...
/Users/USERX/Library/Application Support/Code/User/settings.json
Maybe something internal is not expanding the user home directory ~ shortcut?
sean-mcmanus
commented
4 years ago sean-mcmanus
commented
4 years ago Yeah, seems like we could use more logging between when it queries the compiler and when something goes wrong to cause the compiler's includePaths to not be used.
RogerLevy
commented
4 years ago I am also getting this issue on Ubuntu. Intellisense/code formatting doesn't find any files in /usr/include/
sean-mcmanus
commented
4 years ago @RogerLevy What is your compilerPath and includePath? When you do C/C++: Log Diagnostics are the includePaths correct?
Logonz
commented
4 years ago This is the same issue i have in #4444 It doesn't seem to look into the folders recursively, adding the includePaths as absolutes "solves" the issue.
EDIT: Mine just started working... Don't know what i did but i reopened it as a new workspace and then it reparsed everything from scratch (Reset didn't work before). Updated C/C++ to 0.26.3-insiders2 before trying so maybe this issue is fixed in later versions?
Here it shows that it does not seem to respect the "**" in the configurations file.
We are 3 people who work with the same project with the exact same configuration
They do not get this error. Their editor seems to tag parse correctly.
arixank
commented
4 years ago If anyone has trouble getting c/c++ to run in vscode do watch this video. Link : https://www.youtube.com/watch?v=Axvh6IOp7ac
It has step by step guide on setting up c/c++ on vscode for windows and also some possible error fixes !!
ghost
commented
4 years ago Hi everyone :metal:
@NancyLi1013 NancyLi1013 mentioned this issue yesterday "#include errors detected" #11816
Can u help me guys @michelleangela, @sean-mcmanus , @Colengc
sean-mcmanus
commented
4 years ago @GrayHub-737 Change your C_Cpp.intelliSenseEngineFallback setting to "Disabled". Also, remove the system include paths from includePath. You may also want to remove compilerArgs if that is causing problems.
ghost
commented
4 years ago Thanks for your feedback @sean-mcmanus
The compilerArgs always remove themselves automatically on "c/c++ edit Configurations (UI)". And I have set C_Cpp.intelliSenseEngineFallback setting to "Enable", also the include paths are removed.
But nothing hopeful has happened
ghost
commented
4 years ago Hi @sean-mcmanus ,I no longer have problems with my include paths right now. I learned something from
However every time I try to compile and run the file I receive no output from the integrated terminal. But whenever I debug the file its outputs are easily shown on the external console... What have I done wrong?
sean-mcmanus
commented
4 years ago I don't think integrated terminal support for the debugger has been implemented. I think there's another issue tracking that. @WardenGnaw might know more.
WardenGnaw
commented
4 years ago Integrated terminal is supported for all platforms if you just want to see output. There is no psuedo-tty for macOS so far, so input is broken.
@GrayHub-737 Which OS are you using? Can you share your launch.json?
Could you also share the output of the debug console when you turn on engineLogging?
ghost
commented
4 years ago @WardenGnaw unfortunately I'm no longer faced with that problem anymore right after I restarted my windows machine.
But just to give you an idea of what was happening. Whenever I compile then run my cpp executable file, it'll skip the output part then show me my workspace directory. As if I just directly pressed enter.
tenry92
commented
4 years ago I was also encountering the issue with the "#include errors detected" in (almost) any header file I opened. There was a single header file (which should not have been included in any other header file), that could not find one of its headers, causing the error message on any header file.
In my case, my project roughly looks like this:
My internal_dependency.hpp includes some config.h, that is auto-generated (using CMake). I added "build/
My mylib.code-workspace:
{
"settings": {
"C_Cpp.default_includePath": [
"${workspaceFolder}/include",
"${workspaceFolder}/build/<path to config.h folder>" // <- I added this line
]
}
}
jamesbraza
commented
4 years ago I ran into this today on my MacBook (macOS Catalina 10.15.5).
What solved it for me was:
xcode-select --installbrew upgradeAnd somewhere in this process, the problem was fixed for me.
Yes, I know that I'm not the first user with this problem. But I tried all the different ways explained in other issues to fix the problem and can't get to a solution.
My c_cpp_properties.json:
`{
}`