vscode-cpptools
vscode-cpptools copied to clipboard
Intellisense language version selection arbitrariness
Environment
- OS and Version: MS Windows 10
- VS Code Version: 1.70.2
- C/C++ Extension Version: 1.12.4
- Other extensions you installed (and if the issue persists after disabling them): C++ Extension Pack v1.2.0; CMake v0.0.17 with inferiors; Intellicode v1.2.24; Makefile tools v0.6.0
- If using SSH remote, specify OS of remote machine: Ubuntu 20.04
After last VSCode restart, warnings about forced selection of higher language level started appearing in output window. If these warnings are really describing the plugin logic, its decision to force newer language versions is improper.
I don't know what versions were before restart, due to automatic upgrade during restarts.
The project is single-directory of what is edited in vscode, with external directories of dependence projects (not to be controlled).
The project is makefile-based with own making logic and docker-based compilation. Code analysis alleviation is defined using includePath
and defines
in plugin settings.
Bug Summary and Steps to Reproduce
Bug Summary: The following messages started appearing in "output" window:
[9/1/2022, 9:23:34 AM] For C source files, the cStandard was changed from "c99" to "c17" based on compiler args and querying compilerPath: "/usr/bin/g++" [9/1/2022, 9:23:40 AM] For C++ source files, the cppStandard was changed from "gnu++11" to "c++23" based on compiler args and querying compilerPath: "/usr/bin/g++"
Required language level as C99 and gnu++11 are explicitly specified in project settings (c_cpp_properties.json). Despite the present compiler aptitude, the project shall be restricted to C99 and C++11 due to special target compilation.
Steps to reproduce:
Reopen the project folder and check contents of "output" window.
Expected behavior
No arbitrary selection of language version.
Code sample and Logs
c_cpp_properties.json:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"/usr/lib/gcc/x86_64-linux-gnu/9/include/",
"${workspaceFolder}/**",
"${workspaceFolder}/common/include",
"${workspaceFolder}/include",
],
"defines": [
<... lots of project-specific definitions...>
],
"compilerPath": "/usr/bin/g++",
"cStandard": "c99",
"cppStandard": "gnu++11",
"intelliSenseMode": "linux-gcc-x64",
"configurationProvider": "ms-vscode.makefile-tools",
"compilerArgs": [
"-g -O -std=c++11 -DARCH_X86_64"
]
}
],
"version": 4
}
From log diagnostics:
-------- Diagnostics - 9/1/2022, 9:54:17 AM
Version: 1.12.4
Current Configuration:
{
"name": "Linux",
"includePath": [
"/usr/lib/gcc/x86_64-linux-gnu/9/include/",
"${workspaceFolder}/**",
"${workspaceFolder}/common/include",
"${workspaceFolder}/include",
],
"defines": [
<... skipped as above ...>
],
"compilerPath": "/usr/bin/g++",
"cStandard": "c99",
"cppStandard": "gnu++11",
"intelliSenseMode": "linux-gcc-x64",
"configurationProvider": "ms-vscode.makefile-tools",
"compilerArgs": [
"-g -O -std=c++11 -DARCH_X86_64"
],
"compilerPathIsExplicit": true,
"cStandardIsExplicit": true,
"cppStandardIsExplicit": true,
"intelliSenseModeIsExplicit": true,
"mergeConfigurations": false,
"browse": {
"path": [
"/usr/lib/gcc/x86_64-linux-gnu/9/include/",
"${workspaceFolder}/**",
"${workspaceFolder}/common/include",
"${workspaceFolder}/include",
],
"limitSymbolsToIncludedHeaders": true
}
}
Custom browse configuration:
{
"browsePath": []
}
No active translation units.
Screenshots
Additional context
No response
Hi @netch80 . Can you set "C_Cpp.loggingLevel": "Debug"
and provide the C/C++ log output leading up to the issue?
Note that when using a custom configuration provider, it takes precedence over all of the other settings in the c_cpp_properties.json
. However, your log diagnostics indicates that the custom configuration provider was not used and didn't even provide a 'browse configuration', which it should do early on. So, that information does not seem to match up. Perhaps your log output would help clarify what is happening.
hi @Colengms sorry for delay. I configured the log level as requested to "Debug" and restarted VSCode. The result is identical in sense no another messages appear in output window, only the same twos as in the initial request. If you mean some another log, please suggest where to find it (Windows 10). VSCode is 1.72.2 now, C/C++ v1.12.4 (unchanged).
Hi @netch80 . Could you provide the output from the C/C++
output channel (not the C/C++ Configuration Warnings
channel), with the "C_Cpp.loggingLevel": "Debug"
enabled, leading up to and including the repro of the issue?
It looks like the issue may be with the compiler args. The compileArgs
field expects an array of arguments:
"compilerArgs": [
"-g",
"-O",
"-std=c++11",
"-DARCH_X86_64"
]
As an array, it's assumed not to have shell quoting or escaping, such as in an argv
passed to a main()
. So, spaces are considered literal and part of the same arg. Multiple arguments in the same string (potentially including shell quoting and escaping) is a concept specific to shell command lines. We do support command line parsing of the compilerPath
field, which you could use instead:
"compilerPath": "/usr/bin/g++ -g -O -std=c++11 -DARCH_X86_64",
Hi @Colengms @netch80
I observe similar error. I also set "C_Cpp.loggingLevel": "Debug" as recommended. Here are files from both warning channel and basic channel.
c_cpp_configuration_warnings_output_channel.log c_cpp_output_channel.log
Here is the content of my c_cpp_properties.json:
{
"configurations": [
{
"name": "ARM-GCC",
"includePath": [
"${workspaceFolder}/**",
"${workspaceFolder}/build/zephyr/include/generated/"
],
"defines": [],
"windowsSdkVersion": "10.0.18362.0",
"compilerPath": "C:/gnuarmemb/bin/arm-none-eabi-gcc-10.3.1.exe",
"cStandard": "c11",
"intelliSenseMode": "windows-gcc-arm"
}
],
"version": 4
}
@netch80 That's how you select the channel:
Hi @AndreyDodonov-EH . I suspect the issue you are seeing is different, as netch80's issue seems related to compiler args and your example doesn't involve compiler args.
Looking at your logs, it appears to have successfully configured for arm-none-eabi-gcc-10.3.1.exe
. However, after that, I see:
cpptools/didChangeCppProperties
Attempting to get defaults from C++ compiler in "compilerPath" property: 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe'
It appears to be responding to a change to your c_cpp_properties.json
file. Your log has quite a few occurrences of cpptools/didChangeCppProperties
. Is it possible you have another extension installed that is trying to write to your c_cpp_properties.json
file? Or, perhaps these log included steps you didn't mention? When I load a simple test workspace folder with v1.13.4, I see just one occurrence of cpptools/didChangeCppProperties
. Are you using 1.13.4?
This issue has been closed because it needs more information and has not had recent activity.