Defining enum type compiles ok, but STM32CubeIDE flags syntax error

[StevenG]

Defining the underlying type of an enumeration has been a difficult task until C23 added the feature.  Previously different compilers used different methods and results could vary unexpectedly.

As seen in the image below, STM32CubeIDE v 1.19.0 can recognize this C23 feature and flag mistakes, such as the out-of-range value 0x101 for the 8-bit enum.

As seen in the gcc output below, the mistake is caught by gcc:

This is all as it should be.  The problem is when I remove the fake out-of-range command, gcc works as expected but STM32CubeIDE flags a syntax error:

The build finished with no errors or warnings so gcc 13 understands at least this part of the C23 standard.

Is there a configuration within STM32CubeIDE to prevent displaying a Syntax error for code the compiler understands?

PS

  I checked the generated assembly and it appears that the correct 8-bit code (ldrb) is being generated:

[Ghofrane GSOURI]

Hello @StevenG 

First let me thank you for posting.

As shown in the screenshot below ,  STM32CubeIDE 1.19.10 supports the following C language standards:

• ISO C90 / ANSI C89
• ISO 9899:199409
• ISO C99
• ISO C11
• ISO C17
• ISO C18
• GNU extensions for each of the above (e.g., GNU99, GNU11, GNU17, GNU18)

C23 is not listed: The latest standard available is C18 (ISO C18 or GNU18).

The enum underlying type syntax (enum E : unsigned char { ... }) will not be supported by the current toolchain and will result in a syntax error.

THX

Ghofrane

[Andrew Neil]

Note that the syntax highlighting in the editor is separate from the compiler - so even if you do install a compiler which handles C23, the editor syntax checking may not.

This comes up fairly often; eg,

CubeIDE incorrectly flags __attribute__((fallthrough)) as syntax error.

PS:

May well be a general Eclipse thing, rather than CubeIDE specific:

https://github.com/eclipse-cdt/cdt/issues/1128#:~:text=Is%20the%20C23%20dialect%20supported%3F%20It%20looks%20like%20I%20can%20set%20a%20C23%20standard%20in%20the%20compiler%20settings%20and%20clang%20has%20no%20issue%20compiling%20C23%20code.%20However%2C%20the%20editor%20does%20not%20look%20like%2...

[StevenG]

Correct.  The gcc compiler/linker did the right thing as the assembly showed (which is why I included that image).

The problem lies within either Eclipse's or STM32CubeIDE's syntax highlighter. 

My question was if there was a switch somewhere within STM32CubeIDE to tell the syntax highlighter what standard to follow.

[StevenG]

Note that the current toolchain does support the syntax, it appears it's just STM32CubeIDE's syntax highlighter that does not.

Is there any plan to update the syntax highlighter or a way to adjust how the syntax highlighter works?

[Andrew Neil]

---

@StevenG wrote:

My question was if there was a switch somewhere within STM32CubeIDE to tell the syntax highlighter what standard to follow.

---

I haven't found one.

You can turn off the error highlighting completely:

https://stackoverflow.com/questions/802410/why-does-eclipse-cdt-say-syntax-error-but-compilation-no-problem#:~:text=Alternatively%20you%20can%20turn%20off,for%20C/C%2B%2B%20Indexer%20Markers.

[Andrew Neil]

Does this help: https://stackoverflow.com/a/50128081 ?

It's not entirely clear (to me) what this actually does - is it telling Eclipse to use the GCC preprocessor/parser instead of its own built-in one?

The Eclipse online help seems no more informative:

[bramble]

Not sure if I'm missing something here, but there is a syntax error in your "corrected" version isn't there? You have a comma after 0x43, which is not strictly correct as it's the last item in the enum.

[mfgkw]

A trailing , is ok in an enum list (but not required).

[Ozone]

Exactly, the parser running in the background of the editor is not the target toolchain.
I came across this issue with most of the Eclipse-based IDE I used. Which is one of serveral reasons I dislike Eclipse.