C: CB's knowledge on #defines is unreliable

[hanshuckebein]

Very often, but not always, #defines in header files do not result in ungraying corresponding conditional blocks in the editor.

The same for -D command line options for avr-gcc. Interestingly the command line symbol F_CPU is known to the editor.

[stahta01]

Very often, but not always, #defines in header files do not result in ungraying corresponding conditional blocks in the editor.

The same for -D command line options for avr-gcc. Interestingly the command line symbol F_CPU is known to the editor.

I have noticed the first; but, never saw the second happen. Defines in the CB Compiler project settings have always worked for me.

Tim S.

[hanshuckebein]

I'm using the linux version.

[hanshuckebein]

Here is the proof, that -D compiler options and predefined symbols also do not influence rendering of inactive text in the editor – see the attachment.

I'm using C:B 20.03 on Linux Mint 19.2

[oBFusCATed]

Patches welcome.
Just keep in mind that the macro parser in Scintilla is primitive and doesn't support complex cases, so in theory this feature would never work reliably.

p.s. I've not investigated this deeply, so I would be happy to be proven wrong.

[hanshuckebein]

Just keep in mind that the macro parser in Scintilla is primitive and doesn't support complex cases, so in theory this feature would never work reliably.

Then the best would be a switch to disable that feature, since unreliable highlighting is very confusing in files with a lot of conditional blocks, like in the headers of avr-lib.

[oBFusCATed]

There is already such option. Settings -> Editor -> General -> Somewhere...

[BlueHazzard]

Settings->Editor settings->General settings->C/C++ Editor settings->Interpret #if,#else.....