Re: [PATCH v2] c++/modules: Remember that header units have CMIs

[Jason Merrill <jason@redhat.com>]

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