Explain skipped error-directive configurations in --check-config

[KiritoYG]

When configuration discovery considers an optional macro without a required platform macro, an active #error can skip that configuration. --check-config currently gives no explanation, making the resulting unused-function warning difficult to diagnose. This addresses the requested diagnostic in Trac #6672 comment 5.

Report a suppressible invalidConfiguration information message in --check-config for the #error failures otherwise hidden by existing error handling. Include the configuration's user/automatic defines, the original error text, and source/header location. Preserve the existing error for explicit defines without --force, avoiding a duplicate message. Normal analysis and configuration enumeration remain unchanged; this does not automatically infer the required macro or remove the ordinary unused-function diagnostic.

Validation on Windows with Clang 22.1.8 and CMake/Ninja:

• New regression fails on unchanged production code, then passes with the fix.
• All 5,301 native unit tests pass, with 351 existing TODO assertions. Seven new cases cover valid/inactive configurations, suppression, explicit errors, combined defines, normal analysis and headers; the new ID is present in the error list.
• Six CLI edge cases pass, including relative paths. Four ordinary-analysis invocations produce byte-identical output to the exact-main baseline.
• The latest test-only cleanup binds the combined-defines message by const reference. The prior copy triggered redundantCopyLocalConst in upstream self-check. That diagnostic was reproduced with the original analyzer and is now absent on the changed test file; all 24 TestCppcheck tests pass after rebuilding, and Uncrustify 0.80.1 matches. The full-suite/CLI results above cover the unchanged production implementation; upstream checks for the updated head are pending.
• git diff --check passes. Local build used Debug with PCH disabled and serial compilation after Clang crashed on unchanged code in Release/parallel builds. GUI and non-Windows CI were not run locally.

Please assign this work to KiritoYG if needed. I would like this diagnostic fix considered under the published $10 bounty schedule, subject to acceptance and the required ticket closure. Please confirm its eligibility and the supported settlement route; GitHub Sponsors is available if accepted. No award or payment is being claimed.

[danmar]

This is an AI review. Take it with a grain of salt and feel free to reject it by resolving the comment.

The behavior looks right to me. I tried the test case from the PR via the CLI: --check-config now reports invalidConfiguration for FEATURE=FEATURE, -DFEATURE without --force still gives only the existing preprocessorErrorDirective, and normal analysis is unchanged.

One maintainability concern: (mSettings.userDefines.empty() || mSettings.force) is the negation of showerror in Preprocessor::handleErrors(), and startsWith(output->msg, "#error") repeats the check in Preprocessor::reportOutput(). If one of those is changed later, this will silently start producing duplicates or missing messages. Maybe let the preprocessor tell whether it already reported the #error (for example, a small helper that returns showerror, or a flag/out-parameter from handleErrors()) instead of re-deriving the condition here?

Minor: the location building in invalidConfigurationMessage() (fromNativeSeparators + relativePaths) duplicates Preprocessor::error().