uint8_t and uint32_t get mapped wrong by Intellisense for Arduino Nano 33 BLE #97
Labels
Comments
|
Are you able to locate the source where uint8_t and uint32_t are defined? It's possible there's some incorrect define or intelliSenseMode being used that causes the definition to be skipped in the headers. Info from running C/C++: Log Diagnostics (with the source file active) might help. If you could provide more detailed repro steps I could try the repro. You may also want to try 0.29.0-insiders (https://github.com/microsoft/vscode-cpptools/releases/tag/0.29.0-insiders ). |
|
Thanks @sean-mcmanus for the super-fast reply! With 0.29.0-insiders, code formatting on save appears to be broken (my source file takes forever to save, and there is a message popping up that allows me to cancel formatting - only then the file is actually saved), so I reverted back to the "non-insiders" version. The defines that work correctly are from "[...]/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/sys/_stdint.h" - I assume that's also where the ones for uint8_t and uint32_t should come from, and I don't know why they are skipped and instead take over the wrong definitions from the two other files I mentioned above. I changed logging from error to debug, and this is what I got for the source file: Details
|
|
In case you want to try to reproduce, here is what I did (on macOS 10.15.5):
(To be precise: Before I did all that, I first did "Import Arduino project" for an existing example project I had created with the Arduino IDE, using the same board settings as above - not sure if that potentially affected the configuration files somehow...) |
|
I hit the problem with 0.29.0-insiders: microsoft/vscode-cpptools#5731 . Thanks for reporting that. I also hit the issue with uint8_t on 0.28.3 -- changing the intelliSenseMode to clang-arm fixed the issue for me -- can you try that? I think it's a bug with PlatformIO -- they generate the c_cpp_properties.json and they should be setting the intelliSense mode to arm types for arm platforms....we added ARM intelliSenseModes with 0.28.0 of our extension. Also, we have an issue tracking auto-fixing the intelliSenseMode when the wrong one is used. |
|
Actually, using clang-arm doesn't fix it (it could fix other issues though), but adding "__STATIC_INLINE" to the defines list appears to have fixed it. Not sure if the PlatformIO extension is supposed to add that automatically or if something else is causing that to not get defined. |
|
@sean-mcmanus Great, thanks so much! I can confirm that adding adding "__STATIC_INLINE" to the defines list in "c_cpp_properties.json" fixes the issue also for me! If I understand the situation correctly, this means that PlatformIO needs to change its behavior as follows:
I hope they can adapt that in one of the next releases... Regarding the "clang-arm" setting: I had to revert it back to "clang-x64". While it worked in the simple "empty project" example, it causes issues with several header files in my main project: |
|
Just a note for other noobies like me: As PlatformIO regenerates the "c_cpp_properties.json" file, you need to tell PlatformIO to include the respective define for you using the "build_flags" option, i.e. a minimal working "platformio.ini" for an Arduino Nano 33 BLE looks like this: |
|
Hmm, the clang-arm setting causing missing headers is not expected. Maybe it should be clang-arm64? If the target is 32-bit, it'd be interesting to see if clang-x86 works better or not. |
|
FYI, https://github.com/microsoft/vscode-cpptools/releases/tag/0.29.0-insiders2 has the fix for the bug you hit with 0.29.0-insiders, as well as some other fixes we found while working with PlatformIO-based projects. |
|
Thanks @sean-mcmanus that's great news. I'll give it a try (and also provide feedback on the clang topic) as soon as I can continue to work on our project (I'm currently held up by other priorities, but should be able to return soon) |
|
@sean-mcmanus: Thanks again. I can confirm that 0.29.0-insiders2 fixes the bug for me as well. clang-x86 (instead of clang-arm, which didn't) seems to work, however, PlatformIO overwrites the setting back to clang-x64 when it is regenerating c_cpp_properties.json - and as I had no notable issues with clang-x64 in the first place, I am not particularly worried about that... |
|
Oh, wait, this is new... Now I'm getting an "include error detected" message, when I use clang-x64. It goes away with clang-x86, but I don't know how to make this setting persistent, as noted in my previous post 🙈 |
|
... and more annoying, I get lots of build errors if I add to my platformio.ini |
|
So, the only thing that currently works is manually adapting c_cpp_properties.json to add However, I will lose both modifications whenever PlatformIO chooses to recreate c_cpp_properties.json |
|
The C/C++ extension added clang-x86 mode for 32-bit targets in August 2019 -- not sure if PlatformIO has added support for that yet. I also hit a problem using clang-arm mode -- looks like we force a --target=arm-arm-none-eabi for 32-bit ARM compiler querying as a default, which causes some compilers that don't support that target to exclude all the platform includes -- adding a correct UPDATE: I got the --target compilerArg to work with 0.29.0-insiders2 with my clang set for arm cross compilation after adding the --sysroot compilerArg. |
|
https://github.com/microsoft/vscode-cpptools/releases/tag/0.30.0-insiders added a bunch of updates to auto-handling of ARM intelliSenseModes and added remote ARM support, so let us know if the configuration has gotten worse or better for you. In particular, your workaround of using clang-x86 for ARM may no longer work if we detect the compiler is targetting ARM and for it to clang-arm. |
|
This issue has been automatically marked as stale because it has not had recent activity. Please provide more details or it will be closed if no further activity occurs. Thank you for your contributions. |
|
I don't think the issue is "stale"...it was just never addressed. What details were needed? |
|
I have the same issue. The build succeeds, but the IntelliSense is showing problems for Every identifier from list is marked with red underline in code editor, and hover shows it as undefined, but |
|
@kaliberr44 kaliberr44
Just a guess, but does adding: "defines": [
"BOARD_PCA_10059",
"NRF52840_XXAA"
],to your Regarding the other identifiers... is it possible you haven't told VScode where to look for these header files? Does VScode complain? If you hover over the the |
|
I had "NRF52840_XXAA" in defines, added "BOARD_PCA_10059", but the error still occurs. The code always compile fine. It is the annoying Intellisense issue (the same as mentioned by OP). |
|
Hi guys, could someone put together a simple example to reproduce the issue? I tried a basic code with fixed-length types and it worked just fine with the latest VSCode and ArduinoCore-mbed v1.3.2 on both Windows and Ubuntu: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If I create a new project for an "Arduino Nano 33 BLE" and create test variables of the "stdint" types, I get the following situation:
Hovering over the types gives the following results:
int8_t: typedef __int8_t int8_t => OK
uint8_t:
F12 takes me to line 228 "[...]/.platformio/packages/framework-arduino-nrf52-mbedos/cores/arduino/mbed/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/modules/nrfx/hal/nrf_spi.h"
This does not make any sense, but it looks like Intellisense maps the definition of uint8_t to the return type of the macro defined in that line.
int16_t, uint16_t, int32_t: all OK
uint32_t:
F12 takes me to line 206 of "[...]/.platformio/packages/framework-arduino-nrf52-mbedos/cores/arduino/mbed/features/cryptocell/FEATURE_CRYPTOCELL310/include/crys_rnd.h"
Also here, it looks like Intellisense maps the definition of uint32_t to the return type of the macro defined in that line.
Any help (can also be hacks or workarounds) would be highly appreciated. From past issues, it looks like @sean-mcmanus has been knowledgeable about these topics in the past...
I'm running the following configuration:
PlatformIO Core: 4.3.4
PlatformIO Home: 3.2.3
ms-vscode.cpptools: 0.28.3 (also tried downgrading to 0.26.0 with same result)
VS Code version info:
Version: 1.46.1
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:17:14.222Z (2 wks ago)
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.5.0
The text was updated successfully, but these errors were encountered: