[Bug c++/105595] Coroutines can trigger -Wsubobject-linkage

[arsen at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105595
--- Comment #4 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
hm, actually, is this valid code?

in https://eel.is/c++draft/basic.def.odr#15 the standard says:

For any definable item D with definitions in multiple translation units,
- (15.1) if D is a non-inline non-templated function or variable, [..snip..]

(the above is our case)

the program is ill-formed; a diagnostic is required only if the definable item
is attached to a named module and a prior definition is reachable at the point
where a later definition occurs.  Given such an item, for all definitions of D,
or, if D is an unnamed enumeration, for all definitions of D that are reachable
at any given program point, the following requirements shall be satisfied.

[... ]

- (15.5) In each such definition, corresponding names, looked up according to
  [basic.lookup], shall refer to the same entity, after overload resolution
  ([over.match]) and after matching of partial template specialization
  ([temp.over]), except that a name can refer to:
  - (15.5.1) a non-volatile const object with internal or no linkage if the
    object
    - (15.5.1.1) has the same literal type in all definitions of D,
    - (15.5.1.2) is initialized with a constant expression,
    - (15.5.1.3) is not odr-used in any definition of D, and
    - (15.5.1.4) has the same value in all definitions of D,
    or
    - (15.5.2) a reference with internal or no linkage initialized with a
      constant expression such that the reference refers to the same entity in
      all definitions of D.


... but here we are referring to a name (anon_ns_t) that is in an anonymous
namespace, and that is not a non-volatile const object nor a reference.

we /might/ be doing something wrong for the lambda closure case, though.  I
might need to revisit.

in the case that you make the above inline, only the anon_ns_t warning remains,
if you also make the function anonymous (obviously) the warnings go away
entirely.  I'm not sure there is a valid case where the above can be included
in two TUs.  naturally, if you never include this file twice, it should be
okay, but even the following generates this warning:

  namespace { struct X {}; }
  struct Y { X x; };