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 > > > > >
