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:

[Andrew Neil]

---

@Ozone wrote:

I came across this issue with most of the Eclipse-based IDE I used. 

---

Indeed - it is an Eclipse thing, not specific to CubeIDE.

But it's not unique to Eclipse; eg, the old Atmel Studio (MSVS-based) also did it.

I wonder if VSCode also does it ... ?

[bramble]

Exactly my point. Nothing to do with the compiler.

[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

[Andrew Neil]

---

@A.D. wrote:

does anyone know a solution how to teach the Eclipse code highlighter the new C standard?

---

Does this help ?

[StevenG]

No.  Changing the language mappings didn't help with the Eclipse syntax highlighting not liking the storage specifier in the enumeration definition.

typedef enum SSP_CMDS_E : unsigned char
{
   CMD_ID_REQ = 0x41, // ID Request
   CMD_EXT_ID_REQ = 0x42 // Extended ID Request
} SSP_CMDS_E;

It's either an Eclipse issue or an STM32CubeIDE issue.  Not actually a bug since STM32CubeIDE doesn't claim to support C23 syntax.  If this enumeration wasn't part of an 'over-the-wire' communications definition, I would just use a #define to avoid the issue.  

At this point it's important to remember the job isn't to find a better way to shoot the alligators; the job is to drain the swamp.