-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++ IntelliSense errors in some items in C++ 23 ARM, but compiles #13087
Comments
Could you provide a code snippet of the error to easily reproduce the issue? |
Sorry for the late reply, here's a example.
|
Here's another intermittent example.
This is exclusive to building on arm. If I had to guess, it's because when setting up the configurations in the c_cpp_properties, you mark it as win32. So, VsCode will use #if's for win32 rather than arm, causing it to read references from the GNU toolchain as incompatible. |
Here's the intermittent printf. After I posted this I got it to do it by restoring the settings.json. I also have problems detecting stdlib.h (Again intermittent, but I'll try a repo)
Hoving over files.Assostions, I get "This setting cannot be applied in this workspace. It will be applied when you open the containing workspace folder directly." Clearly, it's being applied if it breaks IntelliSense... Hah just got the stdlib.h error |
@Voidless7125 You'll want to remove the "**" from any include paths that are order-dependent, i.e. any system includes (and potentially any user include paths that contain files with duplicate names or file names in system include folders). Otherwise, the ordering will likely be incorrect and cause the wrong system headers to be used. You can run the C/C++: Log Diagnostics command to view the includes that are used and compare that with the includes that you're using to build and/or that your compiler sets. |
@Voidless7125 Actually, if you're successfully able to query the compilerPath, then you shouldn't be setting any system includes in your include path. But, if you're using the Makefile Tools extension, then the configuration may be coming from that "configurationProvider": "ms-vscode.makefile-tools" , although the system includes may still be from the compilerPath that it's sending. I see
That means it's using recursive includes and it's likely picking the wrong system paths. I'm a little confused which method of configuring you're trying to use. |
I am not the most experienced with C++ so I am sorry If I am not making sense. I have clang 19.1.6 and Arm GCC 14.2.1 with GNU make 4.4.1. My makefile just takes TOOL_INC = -I"$(VEX_SDK_PATH)/$(PLATFORM)/clang/$(HEADERS)/include" / (Full makefile files)
mkenv.mk
mkrules.mk
"then you shouldn't be setting any system includes in your include path." So the thing is, the files are in dir's bellow it, and in C:/Users/%username%/Appdata/Roaming/Code - Insiders\User\globalStorage\vexrobotics.vexcode/sdk\V5\V5_20240802_15_00_00\vexv5\ the compiler is in C:/Users/%username%/Appdata/Roaming/Code - Insiders\User\globalStorage\vexrobotics.vexcode/tools\cpp\toolchain_win32 I tried this:
And it fixed the printf instantly but not the other 2. I also tried switching "intelliSenseMode": "windows-clang-x86", to "intelliSenseMode": "windows-clang-x64", |
Looking at this after my json edit
I only want Also looking at this
is all correct. the pass flags
might be part of the problem. |
Reading the parsing again, there's
How can I force it to only look in /arm-none-eabi/thumb/v7-a+fp/softfp/? |
Any info on How can I force it to only look in /arm-none-eabi/thumb/v7-a+fp/softfp/? |
Environment
Version: 1.96.2 (user setup) (Or insiders 1.97.0)
OS: Windows_NT x64 10.0.26120 (Or 10.0.26100.2605)
C/C++ Extension Version: 1.22.11 (Or v1.23.2)
Bug Summary and Steps to Reproduce
Bug Summary: The C++ extension will error some valid C++ code on C++23.
Attached is IntelliSense saying too many initializer values, but it builds well -Wextra just fine.
Steps to reproduce:
(and more) Do note, just staying in the code editor does not do this, you have to be using Go to definition and other Go to's. Clearing this list fixes most problems, and some are intermittent. (Like printf sometimes is not recognized, and other times it is, and builds fine.)
Expected behavior:
Configuration and Logs
makefile tools
(I am using makefile as a configuration provider, turning it off does nothing.)
Other Extensions
I have tested with only C++ and makefile tools, and I still get this.
Additional context
I have made an issue here before. I am sorry for the late response. My family came up, and I forgot about this.
The text was updated successfully, but these errors were encountered: