$ifdef highlighting

[440bx]

Hello,

Normally, when code is in a {$ifdef <something>} <some code here> {$endif} the highlighting intensity of <some code here> changes depending on whether of not <something> is defined.

when using {$ifdef 0} <some code here> {$endif} the <some code here> is highlighted as if 0 is defined, which it isn't (0 is not an identifier that can be defined.)

IOW, whatever is between {$ifdef 0} and {$endif} should probably be in low intensity to indicate it is not "active" instead of high intensity (which normally indicates code the compiler will compile.)

comments welcome.

[Thaddy]

Do you mean {$IF 0} // which starts a comment
{$ifdef 0} does nothing.

[Khrys]

I think it makes sense to treat  {$ifdef 0} / {$if 0}  as a special type of comment that allows for comment nesting without involving any strange compiler switches 

[Thaddy]

Yes it makes sense since you can define 0

Code: Pascal  [Select][+][-]

1. begin
2. {$define 0}
3. {$ifdef 0}
4.   writeln('test1');
5. {$endif}
6. {$if 0}
7.   writeln('test2'); // never reached...
8. {$endif}
9. end.

The two have completely different meaning......

This is also not a bug, but intentional.

[440bx]

this isn't about whether 0 is defined or not.  It is about the highlighting.

whether 0 is defined or not the highlighting stays the same and, it shouldn't.  When defined what is in its domain should be bright otherwise it should be dim.  That's what happens with normal identifiers but does not happen with numerals (no reason why it shouldn't.)

[Thaddy]

That is a shortcoming in the Lazarus IDE that does not handle {$if 0} correct. It is not treated as a comment.
It does handle {$define 0}{$ifdef 0} correct. (As 0 is just like any other identifier as far as {$ifdef} is concerned.)

[440bx]

again: it's about the highlighting, nothing else.

[Thaddy]

This was about the highlighting...nothing else. The observation you made is just releated to the highligthing of {$if 0} style comments. It does not affect code, only display is not correct.

[Martin_fr]

The $IF and $IFDEF conditions are evaluated by codetools.

There are a few that codetools currently doesn't handle.

If 0 is one of them, the report it as an issue.  Actually for IFDEF that seems to be any numeric constant?

[440bx]

The $IF and $IFDEF conditions are evaluated by codetools.

There are a few that codetools currently doesn't handle.

If 0 is one of them, the report it as an issue.  Actually for IFDEF that seems to be any numeric constant?

That makes sense and, yes, the problem occurs for any numeric constant.

ETA:

reported.

Link   : https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41944
Ticket:41944

[Thaddy]

There is nothing that I did not explained: all of this is intentional and documented. Maybe that the docs can be made clearer.

[paweld]

@Thaddy: @440bx is right, for identifiers that are numbers, the highlighting does not work properly, regardless of whether the identifier is defined or not - see the attached screenshot.

[Thaddy]

Yes, I never wrote otherwise, but the bug report by martin

[Thaddy]

The "problem" with {$ifdef} is that everything that comes after a legal identifier string consisting of the  ' _', 0..9,'A..Z','a..z' is treated as a comment, so {$ifdef 5+1=true} resolves to 5 because +1=true is a comment.
The string is cut off at the first character or symbol that is not in that set.
In this case +.
OTOH {$if 5+1=6} resolves to true because {$if} allows expressions.
And there is where the whole discussion went wrong.
All this is documented. The compiler handles the options correctly but codetools doesn't.

Codetools should parse  ' _', 0..9,'A..Z','a..z' correctly, which is basically the set for any valid pascal identifier char except the escape char &

[paweld]

The compiler handles the options correctly but codetools doesn't.

@440bx didn't mention the compiler at all; his report has been about highlighting in the editor from the very beginning.