missing-field-initializers warning should NOT reporting missing designated initializers

[jamesruan]

#56628 introduce a disruptive change based on a wrong understanding about how designated initializers are meant to be used.

missing-field-initializers should report for user really missing some fields that may lead to potential error behavior.

Designated initializers are more like an extension to default initializer. It's not a kind of implicit init.

struct A {int a; int b;};
A default_init = {}; // a=0, b=0, default init all fields, not reporting warning
A designated_init = {.b=1}; // a=0, b=1, default init a, designated init b; reporting warning now, should not
A real_missing = {1}; // proper use case for this diagnosic flag

[shafik]

Please see my reply on: #56628

[floooh]

FWIW I'm now seeing missing-field-initializer warnings for designated initialization in C mode in the latest Emscripten SDK which breaks my build (because of -Wall -Wextra -Werror).

In C, missing designated initializers are definitely a feature though which shouldn't produce warnings (missing fields are initialized to zero, and some designated-init aware C APIs depend on that feature to detect when a default value needs to be patched in), adding a warning there definitely doesn't make any sense.

I cannot reproduce the problem on native Clang 17.0 in godbolt, so I wonder why Emscripten triggers the warning now. Maybe it's a configuration problem when Emscripten compiles its Clang version, I doubt that they changed anything. In any case I will open an issue in the Emscripten repository.

PS: apparently Emscripten is now on Clang 18.0.0, while Godbolt only has Clang 17.x, so it's most likely a regression in Clang 18. Should I open a new issue for that since it's most likely not an Emscripten thing?

PPS: the Clang 18.0.0 release notes say that the warning should only apply to C++, but it also triggers in C:

• Clang now reports missing-field-initializers warning for missing designated initializers in C++. (#56628)

[shafik]

PS: apparently Emscripten is now on Clang 18.0.0, while Godbolt only has Clang 17.x, so it's most likely a regression in Clang 18. Should I open a new issue for that since it's most likely not an Emscripten thing?

godbolt also have clang (trunk) and clang (assertions trunk)