#541 preprocessor syntax: wrong #if branch highlighted

[Jannick]

CB svn 11112 editor on Win10: preprocessor syntax highlighting bug

//define A // not defined!
#if A == 0
#define msg1 "This is highlighted"  // correct
#endif

#if A > 0
#define msg1 "This is highlighted, too"  // wrong, see NOTE
#endif

NOTE:
If A is not defined, #if defined(A) && f(A) defaults to #if f(A).

[Jannick]

Correcting typo in the first posting just in case: The NOTE should read:

If A is not defined, A is set to zero in expressions, such that #if f(A) defaults to #if f(0).

[Teodor Petrov]

Where is A defined? In the project settings or another header?
This is a feature of the editor component we're using, so it depends on them to handle it correctly. Most of the more complex uses aren't handled correctly.

Please test the same thing in the latest scite release. If reproduces there please report to scintilla developers. Else wait for the update of our version of scintilla to the latest version.

These kind of issues will be solved correctly after semantic highlighting is implemented, but unfortunately I don't see this happenning anytime soon.

[Jannick]

Where is A defined? In the project settings or another header?

Purposely nowhere to show the semantic error.

Please test the same thing in the latest scite release. If reproduces there please report to scintilla developers. Else wait for the update of our version of scintilla to the latest version.

Issue pertains in SciTE 3.7.5, bug filed with the scintilla devs.

These kind of issues will be solved correctly after semantic highlighting is implemented, but unfortunately I don't see this happenning anytime soon.

Agree - but only to the extent that Scite should understand semantics of simple arithmetic expressions to get the highlighting right.

[Jannick]

Suggested cpp parser patch filed with Scintilla devs (https://sourceforge.net/p/scintilla/bugs/1966/#34a0).

Would be great if it could be tested here with CB, as well, since the flawed preprocessor highlighting in CB is confusing and annoying to say the least. I tested it with the latest version of SciTE, but will do that with CB next thing.

@Teodor - not sure it this ticket should remain 'invalid' though.

[ollydbg]

I think this ticket can be opened for discussion.

Re: Conditional Code :: Blocks. highlighting in the editor

The above link is my way to solve the conditional proprocessor issue, it use the our parser's symbol to feed the scintilla's parser, but it looks like scintilla's internal parser has some issue, see another post here:

Lexcpp: allow white space when reading hte macro definition - Google Groups

[Jannick]

@ ollydbg: The patch I proposed to Scintilla works well here - and it remedies the issue of white spaces in macro definitions. I just posted a new patch at Scintilla (see ticket link above) fixing another bug for macros.

BTW: I am not getting any email alert regarding new postings to this thread, although I initiated it. That's weird - and I cannot see any config to change that. Or am I missing something here?

[ollydbg]

The patch I proposed to Scintilla works well here - and it remedies the issue of white spaces in macro definitions. I just posted a new patch at Scintilla (see ticket link above) fixing another bug for macros.

I see in your patch to scintilla (Scintilla / Bugs / #1966 C preprocessor highlighting bug if a variable not defined), you enhanced the preprocessor of scintilla's buildin parser. While, in my post, I just let the CC(our codecompletion plugin) to collect macro definitions for the scintilla, because, scintilla can only handle macro definition in a single cpp file, while our CC may have more informations(such as the #include file hireachy, but currently it is not, but that's doable), so that the scintilla can have better understanding of the macro definition. Although the better way is query CC whether a token is defined from scintilla to CC, but I'm not sure that's doable.

BTW: I am not getting any email alert regarding new postings to this thread, although I initiated it. That's weird - and I cannot see any config to change that. Or am I missing something here?

I'm subscribe to the whole tickets system of the SF's codeblocks site, so I can receive every thing in our ticket system. But normally a user can subscribe to a single thread, I'm not sure.

[Teodor Petrov]

ollydbg: If you don't intend to provide a fix for this problem (soon), then the ticket is better to be closed. The problem is not in C::B's code but in scintilla, so it will either be fixed by updating scintilla or after semantic highlighting using clang or other compiler based parser is implemented.

Then someone has to remember to close this issue.

[Simon]

#if defined(_WIN64) || defined(_WIN32)
/* Microsoft Windows (32-bit or 64-bit). */
#define ROOT "\\"
#else
/* Unix based. */
#define ROOT "/"
#endif

On my Win10, the above code gets highlighted as shown by the bold formatting .
The Unix based #define statement is shown as active, and not the Windows one as you would expect, being on a Windows machine.
But, it does set the correct #define statement, though, ROOT "\\".
It's just confusing. I spent a good couple of hours finding this out.