IAR's C "extension"

[Kochise]

Seriously, IAR :

__no_init volatile union { unsigned char IE1; / Interrupt Enable 1 /

struct { unsigned char WDTIE : 1; / Watchdog Interrupt Enable / unsigned char OFIE : 1; / Osc. Fault Interrupt Enable / unsigned char : 2; unsigned char NMIIE : 1; / NMI Interrupt Enable / unsigned char ACCVIE : 1; / Flash Access Violation Interrupt Enable / }IE1_bit; } @0x0000;

That "@0x0000" breaks the parsing, but those are located into the supplied IAR inc folder and cannot be modified. Any way to get rid of that to parse files ?

Accessing WDTIE becomes ((IE1_bit*)0x0000)->WDTIE using this notation. Handy for embedded, but a killer for the standard.

[mlangkabel]

Hm, sounds like the clang compiler does not like the IAR's extension. Maybe there is a clang flag that you can specify in your Sourcetrail project setup to enable IAR compatibility. If that does not work and the issue you posted is the only issue you have, you could just make a copy of that IAR inc folder, modify that copy and replace it in your project's header search path (maybe just prepend it).

[Kochise]

Wondering why those people do not create their own language from scratch but hack the standard instead. If at least they did it "properly", like using a macro, eg. AT(0x0000), I could have defined an empty macro (eg. #define AT(x)) to get rid of it during the preprocessing stage...