Yes, all decent C/C++ IDEs (Eclipse, Visual Studio, CodeBlocks) use different syntax highlighting for macros and functions. The problem with nested macros like this is a common bad programming practice, highlighted here in the C/C++ FAQ : https://isocpp.org/wiki/faq/inline-functions#inline-vs-macro...

To do that you need to do quite a bit of what the compiler does. For example, you need to know the include search paths, which can get modified by compiler flags, and you need to know what flags got set on the command line, for example to discriminate debug from release builds or to specify C99 compliance.

So, you basically need an IDE to do robust C syntax coloring.

I have personally never come across this. Moreover, "common" C editors are vanilla vim and emacs, which don't actually know what's a macro and what's a function without customization (ctags &c).

Good idea, though. I'd like it.

Some slightly less common IDE-based ones can, like Eclipse, and probably Kdevelop, QtCreator, and MSVC.

There are likely to be add-ons for Vim and Emacs that actually parse the source instead of just pattern matching for syntax highlighting.

With emacs, this actually an ideological choice.

How so?

For that kind of code analysis one wants more detailed information about the source file, like an AST, but Stallman has forbidden that level of detail to be exportable from gcc, and more recently squashed efforts at deeper emacs/clang integrations, both on ideological grounds.

Interesting.

How can deeper integration between any language and tools then be compatible with rms's and/or GNU's and/or the FSF's ideology?

(Maybe the answer is, "Use Lisp since the syntax is the AST." I'm okay with that. :)

I'd also imagine that since the contest is framed as getting around code reviews the code would be inspected using some other source code display tool. These tools certainly wouldn't do any kind of context-sensitive reasoning.