In the CPPTools extension for VS Code, is /** really recursive? - c

Question

I just opened a folder (based on this setup) in VS Code (1.74) containing C code I would like to be handled by the CPPTools extension (1.13.8). Within the folder (.../rd-infra/arm-tf), there is an extensive amount of code in the tree. The default includePath for the folder/workspace includes "${workspaceFolder}/**". However, the second #include in the source (.../rd-infra/arm-tf/bl1/bl1_main.c):
#include <platform_def.h>
shows squiggles and an error:
cannot open source file "platform_def.h"C/C++(1696)
I tried right-clicking on the include to "Go to definition," but this failed.
Doing a search of the tree, I find about 74 versions of this file:
~/Projects/ARMFVPs/FVP_RD_N2/rd-infra/arm-tf$ find . -name 'platform_def.h'
./plat/intel/soc/common/include/platform_def.h
./plat/st/stm32mp1/include/platform_def.h
./plat/hisilicon/poplar/include/platform_def.h
./plat/hisilicon/hikey960/include/platform_def.h
./plat/hisilicon/hikey/include/platform_def.h
./plat/mediatek/mt8186/include/platform_def.h
...
I thought this made the error all the more odd, as I would expect a redundancy issue with so many to choose from. That's not what the error says, but I went ahead and added the specific compiler to .../rd-infra/arm-tf/.vscode/c_cpp_properties.json to see if that helped:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [],
"compilerPath": "${userHome}/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc",
"cStandard": "gnu17",
"cppStandard": "gnu++14",
"intelliSenseMode": "linux-gcc-arm64"
}
],
"version": 4
}
and nothing changed.
So, it appears to me that the ${workspaceFolder}/** is not being recursively searched.
Then I added the specific include directory for the version of the file that applies in my case:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceFolder}/plat/arm/board/rdn2/include",
"${workspaceFolder}/**"
],
"defines": [],
"compilerPath": "${userHome}/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc",
"cStandard": "gnu17",
"cppStandard": "gnu++14",
"intelliSenseMode": "linux-gcc-arm64"
}
],
"version": 4
}
And the squiggles disappeared. I right-clicked on the include to choose "Go to definition," which opened the platform_def.h header file, where there were includes with squiggles as well, showing the same error as before (1696).
So now I'm in the same boat with a new include line:
#include <lib/utils_def.h>
Searching for that file:
~/Projects/ARMFVPs/FVP_RD_N2/rd-infra/arm-tf$ find . -name 'utils_def.h'
./include/lib/utils_def.h
So it looks like ${workspaceFolder}/** isn't even making it one level deep?
I also tried with the full path, both with and without using ${userHome}:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${userHome}/Projects/ARMFVPs/FVP_RD_N2/rd-infra/arm-tf/**"
],
"defines": [],
"compilerPath": "${userHome}/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc",
"cStandard": "gnu17",
"cppStandard": "gnu++14",
"intelliSenseMode": "linux-gcc-arm64"
}
],
"version": 4
}
and it was back to unable to open platform_def.h (1696).
Am I misunderstanding the /** notation?
========= Edit 1 =========
Dumping predefined variables:
userHome: /home/rtillery
workspaceFolder: /home/rtillery/Projects/ARMFVPs/FVP_RD_N2/rd-infra/arm-tf
compiler path: /home/rtillery/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc
Verifying compiler path:
~/Projects/ARMFVPs/FVP_RD_N2/rd-infra/arm-tf$ ll /home/rtillery/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc
-rwxr-xr-x 2 802 802 1213640 Feb 2 2022 /home/rtillery/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc*
And possibly related to #n.m.'s comment, I do get the following error (twice):
[12/20/2022, 10:47:36 AM] Unable to resolve configuration with compilerPath "${userHome}/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc". Using "/usr/bin/gcc" instead.
On the other hand, I don't actually see what the compiler output has to do with CPPTools recursively searching a path provided. (Adding compilerPath above was just a stab in the dark and probably muddied the waters around this question.) Maybe someone can explain if they are?
========= Edit 2 =========
Also, probably not related. In spite of the variable dump above (accomplished using the example at the bottom of this page), the editor shows a different expansion of the ${userHome} predefined variable, which includes the variable expansion and the variable name:
From c_cpp_properties.json:
"compilerPath": "${userHome}/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc",
Error shown in the Problems tab, under the c_cpp_properties.json file:
Cannot find "/home/rtillery/Projects/ARMFVPs/FVP_RD_N2/rd-infra/arm-tf/${userHome}/Projects/ARMFVPs/FVP_RD_N2/rd-infra/tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc".
That's very strange.
Replacing the line with one based on the ${workspaceFolder} instead:
"compilerPath": "${workspaceFolder}/../tools/gcc/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc",
seems to work, as the error disappears.
========= Edit 3 =========
Filed a bug for the other issue mentioned above.