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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
