#define or #undef of a compiler-predefined macro

Reports a #define or #undef naming a macro the compiler predefines - FILE, LINE, APPLE, clang, VA_ARGS and similar - or the defined operator. Defining a feature-test builtin that the compiler may not provide, as in the usual #ifndef __has_feature shim, is not reported.

Redefining or undefining a predefined macro is undefined behavior. Beyond the standard’s verdict, the practical damage is that every header included afterwards - including system and framework headers, which branch on APPLE, clang and the version macros - sees the replacement instead of the real value, so the compiler selects a different set of declarations from the one it was built against. Redefining FILE or LINE additionally corrupts assertion and logging output at the point where it is most needed.

The following code illustrates the pattern detected by this rule:

Give the macro a project-specific name in your own namespace, for example #define XY_SOURCE_FILE "redacted.m", and leave the predefined one alone. Where the goal is to force a build configuration, pass it as a separate -D flag under a name of your own and branch on that.

This detector does not need any configuration.