Espressif ESP-IDF v6.0 Intellisense error: invalid value gnu2b in -std=gnu2b

[gojimmypi]

I recently updated Espressif latest mater ESP-IDF v6 from GitHub, specifically commit 2044fba6 from August 26 . Last update was about a month ago.

With the toolchain update, Intellisense stops working in Visual Studio 2022 with VisualGDB:  invalid value gnu2b in -std=gnu2b

To resolve, enter the text in VisualGDB Project Properties – Intellisense Settings Tab, “Additional flags for C files”:

-std=gnu17 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for pointing this out! We will look into updating the Clang version used by VisualGDB, so that it handles the gnu2b natively. Until then, gnu17, or gnu2x should work.

[gojimmypi]

Heads up the above solution only worked for my local project source code.

For other source code in my component being developed, as well as the entire ESP-IDF source,  I added this to the main project cmake, just before the ending project(projectname):

if(  "$ENV{CONFIG_WOLFSSL_FORCE_V6_INTELLISENSE_FIX}" STREQUAL "1" )
    if(DEFINED IDF_VERSION_MAJOR AND IDF_VERSION_MAJOR GREATER_EQUAL 6)
        message(STATUS "-- Found CONFIG_WOLFSSL_FORCE_V6_INTELLISENSE_FIX, replacing -std=gnu2b with -std=gnu2x")
        if(CMAKE_C_COMPILER_ID MATCHES "Clang")
          string(REPLACE "-std=gnu2b" "-std=gnu2x" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
        endif()
    else()
        message(STATUS "-- Visual Studio Intellisense Fix not needed for this ESP-IDF version=${IDF_VERSION_MAJOR}")
    endif()
else()
    message(STATUS "-- Not replacing -std=gnu2b with -std=gnu2x for Viosual Studio Intellisense fix")
    message(STATUS "-- To enable, define environment variable: CONFIG_WOLFSSL_FORCE_V6_INTELLISENSE_FIX=1")
endif()

# Once the project is loaded, next check for ESP-IDF version 6 or greater.
# Numerous "dangerous relocation: call8: call target out of range: memcpy" errors encountered
# So we'll allow long calls with the -mlongcalls compiler option for all components.
if(IDF_VERSION_MAJOR GREATER_EQUAL 6)
    if(IDF_TARGET STREQUAL "esp32" OR IDF_TARGET STREQUAL "esp32s2" OR IDF_TARGET STREQUAL "esp32s3")
        message(STATUS "mlongcalls for all components")
        idf_build_set_property(COMPILE_OPTIONS "-mlongcalls" APPEND)
    endif()
endif()

Also added this to the local component in the project directory cmake, just after the idf_component_register():

        if(  "$ENV{CONFIG_WOLFSSL_FORCE_V6_INTELLISENSE_FIX}" STREQUAL "1" )
            if(DEFINED IDF_VERSION_MAJOR AND IDF_VERSION_MAJOR GREATER_EQUAL 6)
                message(STATUS "-- Setting -std=gnu17 with target_compile_options $<$:-std=gnu17>")
                target_compile_options(${COMPONENT_LIB} PRIVATE $<$:-std=gnu17>)
            else()
                message(STATUS "-- Visual Studio Intellisense Fix not needed for this ESP-IDF version=${IDF_VERSION_MAJOR}")
            endif()
        else()
            message(STATUS "-- Not setting -std=gnu17 with target_compile_options for Visual Studio Intellisense Fix")
            message(STATUS "-- To enable, define environment variable: CONFIG_WOLFSSL_FORCE_V6_INTELLISENSE_FIX=1")
        endif()

Note that it is optional code, based on the environment variable: CONFIG_WOLFSSL_FORCE_V6_INTELLISENSE_FIX=1

 

I’m note sure exactly which are needed, but in order for syntax highlighting to be reliably restored for me:

• Exit Visual Studio
• Delete ./build directory
• Delete ./visualgdb directory
• Delete ./vs directory
• Restart Visual Studio

[support]

OK, we are not really sure how you managed to get the gnu2b value in the first place (searching ESP-IDF for gnu2b doesn’t find anything, and googling it only finds your post). We would advise double-triple-checking everything to avoid breaking things further.

That said, as promised, we have updated our Clang IntelliSense engine to the latest Clang 21.1. So, it should work with the latest language standards supported by Clang. You can try the new version here:

VisualGDB-6.1.2.5424.msi

Update: the issue could have been related to the old mapping rule that would replace the gnu++23 standard with gnu++2b (as needed by Clang 16.0). Applying that rule to gnu23 would have yielded an invalid value of gnu2b, but then the CMake fix you mentioned would not work because CMake would be outputting gnu23 and the gnu2b would be substituted later.

Either way, the new engine based on Clang 21.1 does not use this mapping, and should work just fine.

[gojimmypi]

The gnu++2b was in my (~ 27th of) August commits  of the ESP-IDF, here in esp-idf/tools/cmake/build.cmake.

The most recent version exhibits a similar syntax highlighting problem, with a different root cause: -std=gnu23 here.

My fix above does still work, although clearly a bit of a hack, needing an additional replace:

string(REPLACE "-std=gnu2b" "-std=gnu23" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")

I’ll try to take the 6.1 for a test drive soon. Thanks for the heads up.

 

[Author]

Posts