`-Wformat-security` false-positive in consteval functions

[vvd170501]

Reproducer:

void FormatFunc(const char* format, ...) __attribute__((__format__(__printf__, 1, 2)));

consteval void Foo() {
    if (false) {
        FormatFunc("test");  // error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
    }
}

constexpr void Bar() {
    if (false) {
        FormatFunc("test");  // ok in constexpr
    }
}

consteval void Baz() {
    if (false) {
        FormatFunc("%s", "test");  // Adding a second arg somehow fixes the warning
    }
}

The warning is present in clang trunk (https://godbolt.org/z/q336xWjzb) and in all recent versions of clang (I checked clang16-clang19).

A more realistic example:

[[noreturn]] void Panic(const char* format, ...) noexcept __attribute__((__format__(__printf__, 1, 2)));

// assert()-like macro which allows adding description to failure message
#define FANCY_ASSERT(x, ...)    \
    if (!(x)) {                 \
        Panic(" " __VA_ARGS__);   \
    }

constexpr int NonZeroConstexpr(int x) {
    FANCY_ASSERT(x);
    return x;
}

constexpr int x1 = NonZeroConstexpr(1);  // ok
// constexpr int x2 = NonZeroConstexpr(0);  // error - Panic(...) is not constexpr

// Same, but with consteval
consteval int NonZeroConsteval(int x) {
    FANCY_ASSERT(x);  // error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
    return x;
}

[vvd170501]

I've tried searching for origin of the warning, found these lines in checkFormatStringExpr. If I change SLCT_NotALiteral to SLCT_NotALiteral, the warning disappears, but I'm not sure if this introduces other unwanted changes in function behavior (also, how does SLCT_NotALiteral not cause a warning in constant-evaluated constexpr functions?).

UPD: This was added in 0bb4d46, which links to https://reviews.llvm.org/D62009. There's a comment regarding format string checking:

If we're in a constant-evaluated context, I think we can and should simply skip all format string checking. There are three cases here:

1. The call with the format attribute is unreached: no diagnostic should be issued.
2. The call with the format attribute is reached but not constant-evaluatable: an error will be produced that we couldn't constant-evaluate.
3. The call with the format attribute is reached and is constant-evaluatable: the constant evaluator needs to check that the format string matches the arguments anyway (because in general we permit non-constant format strings), so it will need to properly handle this case.

Case 3 is currently theoretical (we don't constant-evaluate any format-string functions). But in any case, I think the conclusion remains: we don't need to do these checks in a constant-evaluated context.

So the intended behavior was to ignore format string diagnostics even if the string is not a literal.