C code can not be parsed correctly when upgrade c/c++ plugin to v1.17.x and v1.18.x version

[tenggui]

          For the attached socket project, the issue can be reproduced above C/C++ 1.17.x.  When open the project, the output window will show the following errors. Maybe the IntelliSenseMode and compilerPath were detected incorrectly.

[11/12/2023, 5:14:25 PM] For C++ source files, IntelliSenseMode was changed from "linux-gcc-x64" to "linux-clang-x64" based on compiler args and querying compilerPath: "/usr/bin/clang" [11/12/2023, 5:14:25 PM] IntelliSenseMode was changed because it didn't match the detected compiler. Consider setting "compilerPath" instead. Set "compilerPath" to "" to disable detection of system includes and defines. [11/12/2023, 5:14:25 PM] For C source files, IntelliSenseMode was changed from "linux-gcc-x64" to "linux-clang-x64" based on compiler args and querying compilerPath: "/usr/bin/clang" [11/12/2023, 5:14:25 PM] IntelliSenseMode was changed because it didn't match the detected compiler. Consider setting "compilerPath" instead. Set "compilerPath" to "" to disable detection of system includes and defines.

socket_project.tar.gz

Originally posted by @tenggui in https://github.com/microsoft/vscode-cpptools/issues/11344#issuecomment-1807069047

[tenggui]

I compared the c/c++ log diagnostics between v1.16.3 and v1.18.2 for the same file sockets/initsrv2.c. The memory usage was one of the differences. v1.16.3 used 94MB, but v1.18.2 only used 11MB. The log files are attached. cpptools_1.16.3.log cpptools_1.18.2.log

[tenggui]

Type: Bug

The additional information as below:

Extension version: 1.18.2 VS Code version: Code 1.84.2 (1a5daa3a0231a0fbba4f14db7ec463cf99d7768e, 2023-11-09T10:51:52.184Z) OS version: Windows_NT x64 10.0.22621 Modes: Remote OS version: Linux x64 6.2.0-35-generic

System Info

Item	Value
CPUs	12th Gen Intel(R) Core(TM) i7-12700H (20 x 2688)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	undefined
Memory (System)	63.73GB (19.74GB free)
Process Argv	--crash-reporter-id c80a984a-a37a-465d-ad33-6b30fd2b6095
Screen Reader	no
VM	29%

Item	Value
Remote	SSH: 192.168.134.100
OS	Linux x64 6.2.0-35-generic
CPUs	12th Gen Intel(R) Core(TM) i7-12700H (6 x 2688)
Memory (System)	15.58GB (12.02GB free)
VM	78%

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vsdfh931:30280409
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263:30880072
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
282f8724:30602487
f6dab269:30613381
2i9eh265:30646982
showlangstatbar:30737416
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
welcomedialogc:30887144
pythonnosmt12:30797651
pythonidxpt:30866567
pythonnoceb:30805159
dsvsc013:30795093
dsvsc014:30804076
dsvsc015:30845448
pythontestfixtcf:30871695
pythonregdiag2:30871582
pyreplss2:30886141
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
dsvsc016cf:30886111
dsvsc017cf:30886113
dsvsc018cf:30886115
aa_t_chat:30882232

Extensions (65)

Extension	Author (truncated)	Version
language-x86-64-assembly	13x	3.1.4
Doxygen	bbe	1.0.0
vscode-copy-filename	bra	0.1.1
font-switcher	eva	4.1.0
windowskeybindings	fre	1.58.0
better-cpp-syntax	jef	1.17.2
vscode-json5	mrm	1.0.0
jupyter-keymap	ms-	1.1.2
remote-containers	ms-	0.321.0
remote-ssh	ms-	0.107.0
remote-ssh-edit	ms-	0.86.0
remote-wsl	ms-	0.81.8
vscode-remote-extensionpack	ms-	0.24.0
remote-explorer	ms-	0.5.2023110609
remote-server	ms-	1.5.0
devicetree	plo	0.1.1
HOCON	sab	0.0.1
default-keys-windows	smc	0.0.10
remove-empty-lines	use	1.0.1
vscode-icons	vsc	12.6.0
material-theme	zhu	3.16.2
language-x86-64-assembly	13x	3.1.4
Doxygen	bbe	1.0.0
vscode-doxygen-runner	bet	1.8.0
vscode-copy-filename	bra	0.1.1
path-intellisense	chr	2.8.5
doxdocgen	csc	1.4.0
vscode-office	cwe	3.1.8
vscode-html-css	ecm	1.13.1
EditorConfig	Edi	0.16.4
windows-explorer-context-menu	ele	3.2.1
carbon-now-sh	eri	1.2.0
git-extensions-for-vs-code	for	1.1.3
svgeditor	hen	2.9.0
vscode-ansi	ili	1.1.6
compareit	in4	0.0.2
vscode-gnu-global	jay	0.3.5
better-cpp-syntax	jef	1.17.2
svn-scm	joh	2.17.0
stack-tabs	kyl	0.0.2
vscode-json5	mrm	1.0.0
vscode-language-pack-zh-hans	MS-	1.84.2023110809
vscode-dotnet-runtime	ms-	2.0.0
isort	ms-	2023.10.1
python	ms-	2023.20.0
vscode-pylance	ms-	2023.11.10
jupyter-keymap	ms-	1.1.2
jupyter-renderers	ms-	1.0.17
vscode-jupyter-cell-tags	ms-	0.1.8
vscode-jupyter-slideshow	ms-	0.1.5
cmake-tools	ms-	1.15.31
cpptools	ms-	1.18.2
cpptools-extension-pack	ms-	1.3.0
hexeditor	ms-	1.9.12
devicetree	plo	0.1.1
highlight-words	rsb	0.1.4
markdown-preview-enhanced	shd	0.8.10
cmantic	tde	0.9.0
cmake	twx	0.0.17
intellicode-api-usage-examples	Vis	0.2.8
vscodeintellicode	Vis	1.2.30
vscode-icons	vsc	12.6.0
gitblame	wad	10.5.1
markdown-all-in-one	yzh	3.5.1
material-theme	zhu	3.16.2

(16 theme extensions excluded)

[sean-mcmanus]

@tenggui Your .log files show /usr/bin/gcc being used but your other logging shows it's querying /usr/bin/clang -- which is being used, i.e. where is the /usr/bin/clang coming from in your original post?

Does 1.18.0 work?

[tenggui]

@tenggui Your .log files show /usr/bin/gcc being used but your other logging shows it's querying /usr/bin/clang -- which is being used, i.e. where is the /usr/bin/clang coming from in your original post?

Does 1.18.0 work?

Yes, the incorrect compiler path also let me confused. The compiler path has been set to /usr/bin/gcc obviously in settings.json file, why is it detected as /usr/bin/clang? The issue exists since 1.17.0, if downgrade to 1.16.3, everything is ok.

[tenggui]

Hi, @sean-mcmanus Have you reproduced this issue? I upgrade cpptools to v1.19.0, the issue still exists. There are two c/c++ log files for another source file of another project. For 1.16.3, the sys_reg_public.c was parsed as expected, but for 1.19.0, cpptools reported over 250 warnings. I cannot see any suspectable differences except for the memory usage between 1.16.3 and 1.19.0 from the log files. 1.16.3.txt 1.19.0.txt

[tenggui]

Hi, @sean-mcmanus Maybe this issue has relation to the files.encoding setting option. In my user settings.json file, there is an option line "files.encoding": "gb2312". If I uncomment the line, then reset intellisense database and reload window, the parsing errors will disappear. Could you confirm whether is it a bug?

[Colengms]

Hi @tenggui . The last change that I'm aware of in the C/C++ extension related to files.encoding was in 1.17.0, and was #11210 .

The warnings you originally reported in this issue are directly related to compiler querying. The C/C++ extension will interrogate (query) a compiler it's been configured to use to detect system include paths and system defines. Those warning occurred due to conflicting settings which referred to an IntelliSenseMode for gcc and a compilerPath pointing to clang.

When there is no c_cpp_properties.json and a custom configuration provider (such as CMake Tools) registers with the C/C++ Extension, indicating that it's capable of providing configurations for the current workspace folder, it will be used by default to provide configuration to the C/C++ Extension.

Could you add the setting "C_Cpp.loggingLevel": "Debug" and monitor the C/C++ output pane leading up to the issue? That log should indicate if the issue is indeed due to a custom configuration provider taking over. If so, the issue is that a custom configuration provider should not be used by default if a valid configuration has been provided in settings.json. And a possible work-around would be to move those settings into the corresponding fields of a c_cpp_properties.json file. If the issue is not related to a custom configuration provider, that log might help us figure out where the reference to clang is coming from. It's possible it may be falling back to clang if unable to access gcc for some reason.

Regarding files.encoding: You may run into issues with tag parsing when using this setting, as it will apply globally to all files that are opened directly by the C/C++ extension. This includes system headers as well as project headers. Often, a system may contain UTF8 system headers, leading to issues parsing them due to using the wrong encoding. I posted a comment about this scenario here: https://github.com/microsoft/vscode-cpptools/issues/11407#issuecomment-1714398813

[tenggui]

Hi, @Colengms Thanks for your details. as you said, there might be two issues. The original one is the incorrect compiler path detected and the following is the global file encoding setting. The second I have got the method to work around. But the original incorrect compiler path issue, I also didn't reproduce for several weeks.

[jruffin]

Hello @Colengms and @tenggui,

My team has been having a very similar problem ever since the 1.17 update, and searching for a solution ended up leading me to the present issue.. I can confirm file encoding being involved! Our project used "files.encoding": "iso88591" in its workspace settings.json and removing it completely solved the issue.

Something definitely changed between 1.16 and 1.17, probably in the native cppcode binaries: manually patching 1.17.2 with cppcode binaries copied over from 1.16.3 also makes the problem go away on our setup.