Community
Participate
Working Groups
Build Identifier: CDT 7.0.2.201102110609 When editing C files it would be very helpful to see whether a symbol is undefined in the current context. In my case I have the following code #if (undefSymbol < 4) #include "header1.h" #elif (miscSymbol < 5) #include "header2.h" #endif In this case the first condition resolves to true since the default value of the undefined symbol is 0 and I forgot to defined the symbol. Marking the symbol as undefined would help me a lot finding out those problems where I forgot to define a symbol. Reproducible: Always Steps to Reproduce: See details
Sounds like a potential codan feature.
Where in the UI should the symbol be marked as undefined? Note that if you hover over a symbol, if it's defined then a 'Macro expansion' hover will appear with its expansion, and if it's not defined then no hover will appear - that is one way to tell whether a symbol is defined or not.
I could use the hover but this is cumbersome. Either a codan check that creates an error marker or a specific "decoration" in the editor would be fine. Both is fine to me. It just need to be visible in the editor without the user being forced to hover over the symbol or open context menu, ... (do an additional action)
I don't think a oodan checker is appropriate here, because undefined symbols in preprocessor statements regularly appear in perfectly valid C++ code. Would a different syntax coloring for undefined symbols achieve your objective?
Sure, would be fine for me.
Coloring of unresolved symbols is possible today. Just enable "Problems" in the Syntax Highlighting preferences.
Hmm, thank your for the hint. Never say that entry in the preferences till today. What other kind of "problems" are then also marked? Is it documented somewhere so I can read it myself and you can close this issue ;) Greets Marko
I just noticed that this is about undefined preprocessor symbols. With "Problems" you can only highlight identifiers which did not resolve _after_ preprocessing. It seems Codan marks those identifiers anyway, so this does not provide additional value.
But it is definitely what I need. Thank you. Next time I will RTFM before I open up an issue.
(In reply to comment #9) > But it is definitely what I need. > > Thank you. > > Next time I will RTFM before I open up an issue. If you have what you need, please close the bug as 'invalid'. Thanks!
Issue already fixed by an already existing feature. But this feature was not known to the creator of the issue.
