On 5/22/24 09:01, Patrick Palka wrote:
On Tue, 21 May 2024, Jason Merrill wrote:
On 5/21/24 21:55, Patrick Palka wrote:
On Tue, 21 May 2024, Jason Merrill wrote:
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.
Aha, makes sense. To that end it seems we could strengthen the ce_exact
in comp_except_specs to require == instead of cp_tree_equal equality
when comparing two noexcept-specs; the only ce_exact callers are
cp_check_qualified_type and cxx_type_hash_eq, which should be fine with
that strengthening. This way, we at least do try to reuse a variant if
the (complex or unparsed) noexcept-spec is exactly the same.
Sounds good.
Given that, we probably still want to move the canonical_eh_spec up in
build_cp_fntype_variant, and pass that to cp_check_qualified_type?
And compare the canonical spec directly from cp_check_qualified_type
instead of using comp_except_specs? Then IIUC for
void f() throw(int);
void g() throw(char);
we'd give g the same function type as f, which seems wrong?
Good point, I was confused about what canonical_eh_spec was doing. Your
last patch is OK.
Jason
