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