Phase 10 of GTK3V2MAIN's quality-improvement plan: lock in Phases 4-6's warning-cleanup wins so a future PR can't silently reintroduce them. Phases 4-6 already brought six warning categories to zero for owned code: -Wcast-function-type, -Wsign-compare, -Wimplicit-fallthrough, -Wtype-limits, -Wabsolute-value, -Wunused-but-set-parameter. Right now nothing enforces that -- these only surface in a report-only CI job (compiler-warnings, which passes -Wextra explicitly); the real build doesn't even enable -Wextra.
Fix: added "-Werror=<category>" for all six to the project's real compile flags (PlatformSettings.cmake, both the UNIX and non-MSVC Windows branches, same place Phase 9/SF #660 added its -Wno-missing-field-initializers suppression). Verified each of the six flag names is recognized and behaves identically as an error-promotion switch on both GCC 16 and Clang 22 without requiring -Wall/-Wextra to already be present -- -Werror=X implies enabling -WX on both compilers.</category>
The six categories aren't fully zero project-wide -- the remaining instances are entirely confined to vendored third-party code the project doesn't want to touch: app/tools/halibut/charst/iso2022.c and iso2022s.c (cast-function-type, implicit-fallthrough), app/tools/halibut/deflate.c (sign-compare), app/wlib/gtk3lib/wrapbox/eggwrapbox.c and testwrapbox.c (sign-compare). These build as their own separate CMake targets (xtrkcad-charset, halibut, wrapbox, testwrapbox), so each got a scoped "-Wno-error=<category>" override via target_compile_options, downgrading the relevant categories back to warn-only for just those targets without touching the global gate.</category>
Cross-compiler verification, not just GCC: Clang's diagnostic messages tag the cast-function-type finding under a more specific sub-name (-Wcast-function-type-strict / -Wcast-function-type-mismatch depending on the exact code pattern), but confirmed empirically with a minimal repro that both "-Werror=cast-function-type" (promotes to error) and "-Wno-error=cast-function-type" (demotes back to warning) still correctly match and control it under Clang, so the single flag name works portably across both compilers without needing compiler-specific variants.
Verified: full clean rebuilds under both GCC and Clang (project-wide, including all vendored targets) build without errors and without any new warnings in owned code; ctest 10/10 on both. Also re-verified the plan's category counts against a fresh CI-flag rebuild first -- all six at zero for owned code, matching the plan's snapshot.
Anonymous