On 5/17/24 02:14, Nathaniel Shead wrote:
On Tue, May 14, 2024 at 06:21:48PM -0400, Jason Merrill wrote:
On 5/12/24 22:58, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
I realised as I was looking over this again that I might have spoken too
soon with the header unit example being supported. Doing the following:
// a.H
struct { int y; } s;
decltype(s) f(decltype(s)); // { dg-error "used but never defined" }
inline auto x = f({ 123 });
// b.C
struct {} unrelated;
import "a.H";
decltype(s) f(decltype(s) x) {
return { 456 + x.y };
}
// c.C
import "linkage-3_a.H";
int main() { auto a = x.y; }
Actually does fail to link, because in 'c.C' we call 'f(.anon_0)' but
the definition 'b.C' is f(.anon_1).
I don't think this is fixable, so I don't think this direction is
workable.
Since namespace-scope anonymous types are TU-local, we don't need to
support that for proper modules, but it's not clear to me that we don't
need to support it for header units.
OTOH, https://eel.is/c++draft/module#import-5.3 allows c.C to import a
different header unit than b.C, in which case the type is different and
x violates the odr.
That said, I think that it might still be worth making header modules
satisfy 'module_has_cmi_p', since that is true to the name, and will be
useful in other places we currently use 'module_p ()': in which case we
could instead make all the callers in 'no_linkage_check' do
'module_maybe_has_cmi_p () && !header_module_p ()'; something like the
following, perhaps?
If we need that condition, it should be its own predicate rather than
expecting callers to do that combined check.
But it's not clear to me how this is different from a type in the GMF of
a named module, which is exactly the maybe_has_cmi case; there we could
again see a different version of the type if another TU includes the header.
Jason
