[Bug c++/96868] New: C++20 designated initializer erroneous warnings

[Bug c++/96868] New: C++20 designated initializer erroneous warnings

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

            Bug ID: 96868
           Summary: C++20 designated initializer erroneous warnings
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: matt at godbolt dot org
  Target Milestone: ---

The following code, with -Wall -Wextra, GCC 10.x or trunk, -std=c++20:

```
struct MyObj {
    MyObj();
};

struct Test {
    int a{};
    MyObj obj;
};

Test t() {
    Test t{.a = 1};

    return t;
}

```

Creates a warning:

```
<source>: In function 'Test t()':

<source>:11:18: warning: missing initializer for member 'Test::obj'
[-Wmissing-field-initializers]
   11 |     Test t{.a = 1};
      |                  ^
```

The "obj" is not missing initialization: the generated code correctly calls
MyObj::MyObj().

clang issues no diagnostic on the same code (even with -Weverything).

May be a duplicate of bug #82283 or bug #84685, but those have far more
complex-looking initialiser lists.

CE link: https://godbolt.org/z/b75P6r

[Bug c++/96868] C++20 designated initializer erroneous warnings

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think the warning is correct, Test::obj here is initialized from {}, but
that's not what the user might intend.

[Bug c++/96868] C++20 designated initializer erroneous warnings

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

--- Comment #2 from Matt Godbolt <matt at godbolt dot org> ---
Thanks: I was confused (as I think will many folks be). The examples for
designated initialisers in C++20 on cppreference cite this behaviour as being
useful^. Of course I understand it can be misused, and this indeed a
non-default warning. Thanks for taking the time to reply!

--matt

^:
https://en.cppreference.com/w/cpp/language/aggregate_initialization#Designated_initializers

[Bug c++/96868] C++20 designated initializer erroneous warnings

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Matt Godbolt from comment #2)
> Thanks: I was confused (as I think will many folks be).

Approximately everybody is confused by -Wmissing-field-initializers which is
why people probably shouldn't use it.

It specifically says the **initializer** is missing, not that initialization is
missing. But everybody thinks it's telling them the member is uninitialized.

The manual is at least clear:

> the following code causes such a warning, because "x.h" is implicitly zero

Unfortunately it also says:

> This option does not warn about designated initializers

which might be true for C, but not C++. Should it be true for C++?

[Bug c++/96868] C++20 designated initializer erroneous warnings

[dzhioev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

Pavel Sergeev <dzhioev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dzhioev at gmail dot com

--- Comment #4 from Pavel Sergeev <dzhioev at gmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Matt Godbolt from comment #2)
> > Thanks: I was confused (as I think will many folks be).
> 
> Approximately everybody is confused by -Wmissing-field-initializers which is
> why people probably shouldn't use it.
> 
> It specifically says the **initializer** is missing, not that initialization
> is missing. But everybody thinks it's telling them the member is
> uninitialized.
> 
> The manual is at least clear:
> 
> > the following code causes such a warning, because "x.h" is implicitly zero
> 
> Unfortunately it also says:
> 
> > This option does not warn about designated initializers
> 
> which might be true for C, but not C++. Should it be true for C++?

Do you see any reasons why it shouldn't?

[Bug c++/96868] C++20 designated initializer erroneous warnings

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chfast at gmail dot com

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107434 has been marked as a duplicate of this bug. ***

[Bug c++/96868] C++20 designated initializer erroneous warnings

[chfast at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

--- Comment #6 from Paweł Bylica <chfast at gmail dot com> ---
The workaround is 

MyObj obj = {};

which at least suggests some inconsistency in the compiler internals.

For me this warning should be disabled in C++ when designated initializers are
used and all other fields are value initialized.

[Bug c++/96868] C++20 designated initializer erroneous warnings

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
A similar test.  I'm not sure how we want -Wm-f-i to behave here.

#include <optional>

struct A {
        int a;
        std::optional<int> b;
};

int main()
{
    auto x = A {
        .a = 123 // warns
    };
}

[Bug c++/96868] C++20 designated initializer erroneous warnings

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:0f8f1dee851c23bce19977b2531cf69b4da9f88f

commit r14-1657-g0f8f1dee851c23bce19977b2531cf69b4da9f88f
Author: Marek Polacek <polacek@redhat.com>
Date:   Thu Jun 8 13:52:11 2023 -0400

    doc: Clarification for -Wmissing-field-initializers

    The manual is incorrect in saying that the option does not warn
    about designated initializers, which it does in C++.  Whether the
    divergence in behavior is desirable is another thing, but let's
    at least make the manual match the reality.

            PR c/39589
            PR c++/96868

    gcc/ChangeLog:

            * doc/invoke.texi: Clarify that -Wmissing-field-initializers
doesn't
            warn about designated initializers in C only.

[Bug c++/96868] C++20 designated initializer erroneous warnings

[roland at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868

roland at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roland at gnu dot org

--- Comment #9 from roland at gnu dot org ---
IMHO there's a good case to be made for never warning for designated
initializers, even for fields that have uninitialized default-construction.
When using a designated initializer, `= {.a=value}` doesn't leave any field `b`
uninitialized, it initializes it as `= {}` would, i.e. safely zero for base
types, etc.  When I write `= {.a=value}` that default-or-zero-initialization of
the other fields is exactly what I intended, and I know well that omitted
fields in an initializer are different from leaving the fields uninitialized.

Clearly opinions on this vary.  It seems like it merits having separable option
configuration: `-Wmissing-field-initializers`,
`-Wmissing-designated-field-initializers`. If that flexibility is available,
then it's of less concern what the default state with just
`-Wmissing-field-initializers` or `-Wextra` is.

The separate question remains whether "missing initializer" vs "missing
(explicit) initialization" should also be distinguished differently in the
available warning states than what we have today.  I don't have much opinion
about that one as long as there's a way for me to say that:
```
struct s { int a, b; };
s foo = {.a=1};
```
is acceptable without warning in C++, even if it requires a different option
state than to accept:
```
struct s { int a; int b = 0; };
s foo = {.a=1};
```