On 5/21/24 17:27, 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.
My concern is that if we're building a function type multiple times with
the same noexcept-spec, this patch would mean creating multiple
equivalent function types instead of reusing one already created for the
same function.
+ 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.
The idea that this optimization could make a difference raised the
concern above.
Jason
