================
@@ -3,6 +3,11 @@
// RUN: %clang_cc1 -fblocks -fsyntax-only -verify -Wformat-nonliteral -isystem
%S/Inputs -triple=x86_64-unknown-fuchsia %s
// RUN: %clang_cc1 -fblocks -fsyntax-only -verify -Wformat-nonliteral -isystem
%S/Inputs -triple=x86_64-linux-android %s
+// expected-note@-5{{format string was constant-evaluated}}
+// ^^^ there will be a <scratch space> SourceLocation caused by the
----------------
apple-fcloutier wrote:
@cor3ntin I looked into this and there's about 50 distinct DiagIDs for
format-related issues, which is impractical to for check ahead of time, and
impractical to maintain as format diagnostics expand. Most/all of them can be
controlled as an aggregate by the -Wformat and -Wformat=2 warning groups. This
would be practical to check, but I think that the only facilities we have to
check whether diagnostics are enabled are based on DiagIDs rather than groups.
For what it's worth, I'm less worried than you: when the format string is a
function call, [we _already_ try to evaluate
it](https://github.com/llvm/llvm-project/blob/16c84c4475b909d2de455a44139643c03fe3fe25/clang/lib/Sema/SemaChecking.cpp#L6225).
However, the result is discarded if the lvalue base is not a string literal.
This PR expands the technique as a universal fallback, but I expect the
expensive case to be function calls since I think that's the only way to get
control flow (aside from expression statements).
I can try to improve this to avoid having to evaluate the string twice, though.
https://github.com/llvm/llvm-project/pull/135864
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
