This seems to imply that if INVARIANTS is not set, DIAGNOSTIC is irrelevant. Picking a random file with DIAGNOSTIC in it (kern_clock.c) suggest that this isn't the usual practice. So the #endif for INVARIANTS ought to be before the #ifdef for DIAGNOSTIC, among other rearrangements.

So now I've read your related email. I yield. I won't pretend to know what exactly INVARIANTS and DIAGNOSTICS are supposed to mean.

Wouldn't you want to include the consistent() function if *either* INVARIANTS or DIAGNOSTICS were defined, and then default vmmap_check to 0 or 1 depending on the settings of INVARIANTS and DIAGNOSTICS?

I think that's true in practice: DIAGNOSTIC is basically meant to be an extension of INVARIANTS. The difference is that we want INVARIANTS kernels to be performant enough to be usable as a general-purpose OS, whereas DIAGNOSTIC is mainly useful for running tests or for debugging a specific issue. I can't imagine a scenario where one would configure DIAGNOSTIC without INVARIANTS. It might be more correct to compile the consistency checking under INVARIANT_SUPPORT rather than INVARIANTS, though. (See sys/conf/NOTES for a definition.)

I'll note also that the pattern of

#ifdef DIAGNOSTIC
KASSERT(...);
#endif

is not uncommon, but KASSERT is a no-op unless INVARIANTS is configured.