Re: [PATCH] c++: canonicity of fn types w/ complex eh specs [PR115159]

[Patrick Palka <ppalka@redhat.com>]

On Tue, 21 May 2024, Patrick Palka wrote:

> On Tue, 21 May 2024, Jason Merrill wrote:
> 
> > On 5/21/24 15:36, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > > 
> > > Alternatively, I considered fixing this by incrementing
> > > comparing_specializations around the call to comp_except_specs in
> > > cp_check_qualified_type, but generally for types whose identity
> > > depends on whether comparing_specializations is set we need to
> > > use structural equality anyway IIUC.
> > 
> > Why not both?
> 
> I figured the latter change isn't necessary/observable since
> comparing_specializations would only make a difference for complex
> exception specifications, and with this patch we won't even call
> cp_check_qualified_type on a complex eh spec.
> 
> > 
> > > +  bool complex_p = (cr && cr != noexcept_true_spec
> > > +		    && !UNPARSED_NOEXCEPT_SPEC_P (cr));
> > 
> > Why treat unparsed specs differently from parsed ones?
> 
> Unparsed specs are unique according to cp_tree_equal, so in turn
> function types with unparsed specs are unique, so it should be safe to
> treat such types as canonical.  I'm not sure if this optimization
> matters though; I'm happy to remove this case.

FWIW if we do get rid of this case then I think in
fixup_deferred_exception_variants we can assert TYPE_STRUCTURAL_EQUALITY_P
is already set instead of having to set it.

> 
> > 
> > Jason
> > 
> > 
>