[Daniel Jump (DanielJump)]

Why

Issue #1620 identified warning regressions that normal Level4 builds do not catch. This PR makes the stricter warning surface part of CI for the compiler and every project that compiles generated projections.

Current state

The branch is intentionally still in assessment mode at 548a327d:

• EnableAllWarnings is applied after project-local settings through Directory.Build.targets.
• Compiler, test, natvis, and NuGet validation builds opt into that policy.
• TreatWarningAsError is temporarily disabled so CI can collect the complete warning inventory.

The local warning inventory is now classified. The initial report was dominated by repeated diagnostics from generated headers, the Windows SDK, Catch, and normal /Wall implementation and optimization noise. Source defects and policy changes have been separated so this PR does not hide defects with broad suppressions.

Prerequisite fixes

These PRs should land before strict enforcement is restored here:

• Add a guid constructor overload taking Data4 by reference to array #1622 - add the guid constructor needed to eliminate brace-elision diagnostics.
• Suppress non-virtual destructor warnings in the generated headers #1623 - handle non-virtual-destructor diagnostics in generated projections.
• Remove obsolete warning disables from base_macros.h #1625 - remove obsolete warning disables from base_macros.h.
• Fix remaining strict compiler warnings #1641 - fix the remaining cppwinrt source and test diagnostics without suppressions.

Related bugprone cleanup discovered during the assessment is independently tracked in #1642.

Final enforcement update

After the prerequisite fixes merge, this branch will be refreshed from master and updated to:

• restore warnings-as-errors;
• use MSVC external-header handling for angle-bracket includes and disable warnings from external headers;
• mark vendored Catch as a system header;
• centrally disable known non-actionable /Wall implementation, layout, optimization, and compatibility noise, including postponing the signed/unsigned conversion mismatch cleanup;
• narrowly suppress the runtime non-literal format string diagnostic in text_writer;
• narrowly suppress the non-virtual-destructor diagnostic around WRL SDK includes;
• narrowly suppress the intentional member-function override diagnostics in override behavior tests;
• narrowly suppress the required GetProcAddress function-pointer conversion diagnostic.

A local combined MSVC x64 Debug build with /Wall /WX passes with the prerequisite changes and planned enforcement update applied. The final branch will be validated again against current master, including CI coverage for MSVC and clang-cl, before warnings-as-errors is published.

[Ryan Shepherd (DefaultRyan)]

Thanks for starting this. The compiler project doesn't actually consume the generated headers, though. We should enable the stricter, build-breaking options on the test projects as well to verify that we don't regress and re-introduce new warnings.

[Daniel Jump (DanielJump)]

AI-generated

Updated in 687be84. The strict warning policy is now applied after project-local settings through a CI opt-in in Directory.Build.targets, and the opt-in is passed to compiler, test, natvis, and NuGet validation builds. This means the generated headers are compiled under EnableAllWarnings plus TreatWarningAsError, rather than only compiling cppwinrt.exe with those settings.

[Daniel Jump (DanielJump)]

AI-generated

I ran a local MSVC x64 Debug solution build with /Wall and /WX- before making warning fixes. It produced 237,297 warning emissions, deduplicated to 41,980 file/line/code/message diagnostics. Most are repeated generated-header, Windows SDK, Catch, and standard /Wall warnings.

Commit 548a327 keeps the strict warning level across compiler, test, natvis, and NuGet validation projects but temporarily disables warnings-as-errors, so CI can produce a complete cross-configuration inventory. I will classify that output before restoring the build-breaking setting or changing source.

[Charles Milette (sylveon)]

Why not use /W:external to check non-cppwinrt headers with /W4 instead of /Wall

[Daniel Jump (DanielJump)]

AI-generated

Yes, the final enforcement update uses MSVC external-header handling rather than treating SDK and other angle-bracket headers as cppwinrt source. The planned MSBuild settings are TreatAngleIncludeAsExternal=true and ExternalWarningLevel=TurnOffAllWarnings, with vendored Catch also marked as a system header. The PR remains in assessment mode until the prerequisite source-fix PRs merge.