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

[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]

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%20it%20supports%20C23%20as%20it%20is%20giving%20errors%20on%20C23%20features.%20When%20is%20C23%20support%20planned%3F

[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.

[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).

[A.D.]

OK so we all agree that it has nothing to do with the selected toolchain, but is the Eclipse Language Server. But does anyone know a solution how to teach the Eclipse code highlighter the new C standard?

[bramble]

I wouldn't!  Although a comma in that case is digested by the toolchain, it is syntactically incorrect. This is rather like JSON which some lazy coders scatter with commas at the end of a list only to find that some JSON parsers don't mind and others fall over in a heap.

So rather than modifying the tool to mask a trivially fixed coding error, why not fix that error? 

Bear in mind that compilers evolve forever and the next version may indeed choke on that comma.

I think that the language settings in Eclipse can be edited if you really want to modify the tool to mask this issue.

[Andrew Neil]

---

@bramble wrote:

it is syntactically incorrect.

---

Is it, though?

https://en.cppreference.com/w/cpp/language/enum.html#:~:text=and%20its%20enumerators.-,2),A%20trailing%20comma%20can%20follow%20the%20enumerator%2Dlist.,-3)

 

https://stackoverflow.com/questions/792753/is-the-last-comma-in-c-enum-required 

 

PS:

Even if it is, the question remains valid as there are other issues where the Eclipse parsing gets it wrong; eg:

C23 syntax highlighting in STM32CubeIDE (e.g. constexpr)

CubeIDE incorrectly flags __attribute__((fallthrough)) as syntax error - which isn't even C23