c++ missing-field-initializer warning regression on trunk/18rc.

[pawelsopensource]

hi,
the recent clang-18rc introduces massive warning-regression in c++ code base. it reports warning for fields with default ctor.
https://godbolt.org/z/3vsd7G3Kd

[shafik]

I believe this is intentional but we have a PR open to add a specific option to turn this off and I think it would apply to this case: #81364

A quick fix would be to add {} to field s e.g: https://godbolt.org/z/1b4jfM5o3

#include <string>

struct T {
    int i;
    bool b = false;
    std::string s{};
}; 

int main() {
    T t = { .i = 0 };
}

CC @Fznamznon @AaronBallman

[AaronBallman]

That option was landed in 7df43cc but it landed after 18.x was branched.

The behavior is consistent between Clang and GCC for this: https://godbolt.org/z/e31nrrr7e

Closing this as not being a defect as it's behaving by design.

[tiagomacarios]

@AaronBallman What is the "design" here? s is being initialized. Isn't the warning incorrect?

[AaronBallman]

@AaronBallman What is the "design" here? s is being initialized. Isn't the warning incorrect?

This functionality was implemented 16 years ago to match GCC, so there's a bit of "lost to the mists of time" in terms of any discussion about design.

As best I can tell, the original design intent was to diagnose when initializing a structure without using designated initializers and not initializing all of the fields that can be initialized (so ignores things like unnamed bit-fields). In the intervening years, C++ initialization got more features. Now it seems that explicit in-class initializers are also taken into consideration, but default constructors are not. So I think the design these days is effectively: is there an explicit initialization of the field, either within the initializer list or with an in-class initializer, quite likely for enforcing code readability and to catch when new fields are added to a class.