[clang] Include [[clang::require_explicit_initialization]] warnings in system headers (PR #141133)

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Wed May 28 12:04:00 PDT 2025


zygoloid wrote:

> Its more that we assume/like to assume that the Standard Library always 'does the right thing', even if it does so in ways that look 'wrong'. So we suppress warnings in the standard library headers, since they are assumed to all be false-positives.
> 
> This of course is an interesting 'that assumption is not perfectly true' anymore type of situation.

For me the concern here is minimal: the standard library should *never* be "inventing" its own way of initializing a user-defined type. If the standard library is performing an initialization, it should either have a reason to believe the initialization works (either because it owns the type being initialized -- never a problem here unless the standard library itself starts using this attribute -- or because the user of the standard library used it in a way that implies that the initialization works -- which is exactly the case in which we want a warning), or it should be testing whether the initialization works (eg, in a SFINAE context).

I wonder if a different approach to this problem would be to make the diagnostic produced by this attribute be an error rather than a warning. That'd make it rather more clear that it should be produced even in system headers :) (And we then shouldn't disable it in unevaluated operands -- instead SFINAE could handle the relevant cases there.)

https://github.com/llvm/llvm-project/pull/141133


More information about the cfe-commits mailing list