This patch implements P2564, described at <wg21.link/p2564>, whereby
certain functions are promoted to consteval. For example:
consteval int id(int i) { return i; }
template <typename T>
constexpr int f(T t)
{
return t + id(t); // id causes f<int> to be promoted to consteval
}
void g(int i)
{
f (3);
}
now compiles. Previously the code was ill-formed: we would complain
that 't' in 'f' is not a constant expression. Since 'f' is now
consteval, it means that the call to id(t) is in an immediate context,
so doesn't have to produce a constant -- this is how we allow consteval
functions composition. But making 'f<int>' consteval also means that
the call to 'f' in 'g' must yield a constant; failure to do so results
in an error. I made the effort to have cc1plus explain to us what's
going on. For example, calling f(i) produces this neat diagnostic:
w.C:11:11: error: call to consteval function 'f<int>(i)' is not a constant expression
11 | f (i);
| ~~^~~
w.C:11:11: error: 'i' is not a constant expression
w.C:6:22: note: 'constexpr int f(T) [with T = int]' was promoted to an immediate function because its body contains an immediate-escalating expression 'id(t)'
6 | return t + id(t); // id causes f<int> to be promoted to consteval
| ~~^~~
which hopefully makes it clear what's going on.
Implementing this proposal has been tricky. One problem was delayed
instantiation: instantiating a function can set off a domino effect
where one call promotes a function to consteval but that then means
that another function should also be promoted, etc.
In v1, I addressed the delayed instantiation problem by instantiating
trees early, so that we can escalate functions right away. That caused
a number of problems, and in certain cases, like consteval-prop3.C, it
can't work, because we need to wait till EOF to see the definition of
the function anyway. Overeager instantiation tends to cause diagnostic
problems too.
In v2, I attempted to move the escalation to the gimplifier, at which
point all templates have been instantiated. That attempt flopped,
however, because once we've gimplified a function, its body is discarded
and as a consequence, you can no longer evaluate a call to that function
which is required for escalating, which needs to decide if a call is
a constant expression or not.
Therefore, we have to perform the escalation before gimplifying, but
after instantiate_pending_templates. That's not easy because we have
no way to walk all the trees. In the v2 patch, I use two vectors: one
to store function decls that may become consteval, and another to
remember references to immediate-escalating functions. Unfortunately
the latter must also stash functions that call immediate-escalating
functions. Consider:
int g(int i)
{
f<int>(i); // f is immediate-escalating
}
where g itself is not immediate-escalating, but we have to make sure
that if f gets promoted to consteval, we give an error.
A new option, -fno-immediate-escalation, is provided to suppress
escalating functions.
v2 also adds a new flag, DECL_ESCALATION_CHECKED_P, so that we don't
escalate a function multiple times, and so that we can distinguish between
explicitly consteval functions and functions that have been promoted
to consteval.
In v3, I removed one of the new vectors and changed the other one
to a hash set. This version also contains numerous cleanups.
v4 merges find_escalating_expr_r into cp_fold_immediate_r. It also
adds a new optimization in cp_fold_function.
v5 greatly simplifies the code.
v6 simplifies the code further and removes an ff_ flag.
v7 removes maybe_promote_function_to_consteval and further simplifies
cp_fold_immediate_r logic.
v8 removes maybe_store_immediate_escalating_fn.
PR c++/107687
PR c++/110997
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Update __cpp_consteval.
* c-opts.cc (c_common_post_options): Pre-C++20, unset
flag_immediate_escalation.
* c.opt (fimmediate-escalation): New option.
gcc/cp/ChangeLog:
* call.cc (in_immediate_context): No longer static.
* constexpr.cc (cxx_eval_call_expression): Adjust assert.
* cp-gimplify.cc (deferred_escalating_exprs): New vec.
(remember_escalating_expr): New.
(enum fold_flags): Remove ff_fold_immediate.
(immediate_escalating_function_p): New.
(unchecked_immediate_escalating_function_p): New.
(promote_function_to_consteval): New.
(cp_fold_immediate): Move above. Return non-null if any errors were
emitted.
(maybe_explain_promoted_consteval): New.
(cp_gimplify_expr) <case CALL_EXPR>: Assert we've handled all
immediate invocations.
(taking_address_of_imm_fn_error): New.
(cp_fold_immediate_r): Merge ADDR_EXPR and PTRMEM_CST cases. Implement
P2564 - promoting functions to consteval.
<case CALL_EXPR>: Implement P2564 - promoting functions to consteval.
(cp_fold_r): If an expression turns into a CALL_EXPR after cp_fold,
call cp_fold_immediate_r on the CALL_EXPR.
(cp_fold_function): Set DECL_ESCALATION_CHECKED_P if
deferred_escalating_exprs does not contain current_function_decl.
(process_and_check_pending_immediate_escalating_fns): New.
* cp-tree.h (struct lang_decl_fn): Add escalated_p bit-field.
(DECL_ESCALATION_CHECKED_P): New.
(immediate_invocation_p): Declare.
(process_pending_immediate_escalating_fns): Likewise.
* decl2.cc (c_parse_final_cleanups): Set at_eof to 2 after all
templates have been instantiated; and to 3 at the end of the function.
Call process_pending_immediate_escalating_fns.
* error.cc (dump_template_bindings): Check at_eof against an updated
value.
* module.cc (trees_out::lang_decl_bools): Stream escalated_p.
(trees_in::lang_decl_bools): Likewise.
* pt.cc (push_tinst_level_loc): Set at_eof to 3, not 2.
* typeck.cc (cp_build_addr_expr_1): Don't check
DECL_IMMEDIATE_FUNCTION_P.
gcc/ChangeLog:
* doc/invoke.texi: Document -fno-immediate-escalation.
libstdc++-v3/ChangeLog:
* testsuite/18_support/comparisons/categories/zero_neg.cc: Add
dg-prune-output.
* testsuite/std/format/string_neg.cc: Add dg-error.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/consteval-if10.C: Remove dg-error.
* g++.dg/cpp23/consteval-if2.C: Likewise.
* g++.dg/cpp23/feat-cxx2b.C: Adjust expected value of __cpp_consteval.
* g++.dg/cpp26/feat-cxx26.C: Likewise.
* g++.dg/cpp2a/consteval-memfn1.C: Add dg-error.
* g++.dg/cpp2a/consteval11.C: Likewise.
* g++.dg/cpp2a/consteval3.C: Adjust dg-error.
* g++.dg/cpp2a/consteval34.C: Add dg-error.
* g++.dg/cpp2a/consteval36.C: Likewise.
* g++.dg/cpp2a/consteval9.C: Likewise.
* g++.dg/cpp2a/feat-cxx2a.C: Adjust expected value of __cpp_consteval.
* g++.dg/cpp2a/spaceship-synth9.C: Adjust dg-error.
* g++.dg/cpp2a/consteval-prop1.C: New test.
* g++.dg/cpp2a/consteval-prop10.C: New test.
* g++.dg/cpp2a/consteval-prop11.C: New test.
* g++.dg/cpp2a/consteval-prop12.C: New test.
* g++.dg/cpp2a/consteval-prop13.C: New test.
* g++.dg/cpp2a/consteval-prop14.C: New test.
* g++.dg/cpp2a/consteval-prop15.C: New test.
* g++.dg/cpp2a/consteval-prop16.C: New test.
* g++.dg/cpp2a/consteval-prop17.C: New test.
* g++.dg/cpp2a/consteval-prop18.C: New test.
* g++.dg/cpp2a/consteval-prop19.C: New test.
* g++.dg/cpp2a/consteval-prop20.C: New test.
* g++.dg/cpp2a/consteval-prop2.C: New test.
* g++.dg/cpp2a/consteval-prop3.C: New test.
* g++.dg/cpp2a/consteval-prop4.C: New test.
* g++.dg/cpp2a/consteval-prop5.C: New test.
* g++.dg/cpp2a/consteval-prop6.C: New test.
* g++.dg/cpp2a/consteval-prop7.C: New test.
* g++.dg/cpp2a/consteval-prop8.C: New test.
* g++.dg/cpp2a/consteval-prop9.C: New test.
This constructor should only ever be used with a literal 0 as the
argument, so we can make it consteval. This has the nice advantage that
it is expanded immediately in the front end, and so GDB will never step
into the __cmp_cat::__unseq::__unseq(__unseq*) constructor that is
uninteresting and probably confusing to users.
libstdc++-v3/ChangeLog:
* libsupc++/compare (__cmp_cat::__unseq): Make ctor consteval.
* testsuite/18_support/comparisons/categories/zero_neg.cc: Prune
excess errors caused by invalid consteval calls.
This paper is resolving the problem of well-formed C++17 code becoming
ambiguous in C++20 due to asymmetrical operator== being compared with itself
in reverse. I had previously implemented a tiebreaker such that if the two
candidates were functions with the same parameter types, we would prefer the
non-reversed candidate. But the committee went with a different approach:
if there's an operator!= with the same parameter types as the operator==,
don't consider the reversed form of the ==.
So this patch implements that, and changes my old tiebreaker to give a
pedwarn if it is used. I also noticed that we were giving duplicate errors
for some testcases, and fixed the tourney logic to avoid that.
As a result, a lot of tests of the form
struct A { bool operator==(const A&); };
need to be fixed to add a const function-cv-qualifier, e.g.
struct A { bool operator==(const A&) const; };
The committee thought such code ought to be fixed, so breaking it was fine.
18_support/comparisons/algorithms/fallback.cc also breaks with this patch,
because of the similarly asymmetrical
bool operator==(const S&, S&) { return true; }
As a result, some of the asserts need to be reversed.
The H test in spaceship-eq15.C is specified in the standard to be
well-formed because the op!= in the inline namespace is not found by the
search, but that seems wrong to me. I've implemented that behavior, but
disabled it for now; if we decide that is the way we want to go, we can just
remove the "0 &&" in add_candidates to enable it.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
gcc/cp/ChangeLog:
* cp-tree.h (fns_correspond): Declare.
* decl.cc (fns_correspond): New.
* call.cc (add_candidates): Look for op!= matching op==.
(joust): Complain about non-standard reversed tiebreaker.
(tourney): Fix champ_compared_to_predecessor logic.
(build_new_op): Don't complain about error_mark_node not having
'bool' type.
* pt.cc (tsubst_copy_and_build): Don't try to be permissive
when seen_error().
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/spaceship-eq15.C: New test.
* g++.dg/cpp0x/defaulted3.C: Add const.
* g++.dg/cpp2a/bit-cast7.C: Add const.
* g++.dg/cpp2a/spaceship-rewrite1.C: Expect error.
* g++.dg/cpp2a/spaceship-rewrite5.C: Expect error.
* g++.old-deja/g++.jason/byval2.C: Expect error.
* g++.old-deja/g++.other/overload13.C: Add const.
libstdc++-v3/ChangeLog:
* testsuite/18_support/comparisons/algorithms/fallback.cc: Adjust
asserts.
This removes a FIXME in <compare>, defining the total order for
floating-point types. I originally opened PR96526 to request a new
compiler built-in to implement this, but now that we have std::bit_cast
it can be done entirely in the library.
The implementation is based on the glibc definitions of totalorder,
totalorderf, totalorderl etc.
I think this works for all the types that satisfy std::floating_point
today, and should also work for the types expected to be added by P1467
except for std::bfloat16_t. It also supports some additional types that
don't currently satisfy std::floating_point, such as __float80, but we
probably do want that to satisfy the concept for non-strict modes.
libstdc++-v3/ChangeLog:
PR libstdc++/96526
* libsupc++/compare (strong_order): Add missing support for
floating-point types.
* testsuite/18_support/comparisons/algorithms/strong_order_floats.cc:
New test.
This adds the [[nodiscard]] attribute to all conversion operators,
comparison operators, call operators and non-member functions in
<compare>. Nothing in this header except constructors has side effects.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* libsupc++/compare (partial_ordering, weak_ordering)
(strong_ordering, is_eq, is_neq, is_lt, is_lteq, is_gt, is_gteq)
(compare_three_way, strong_order, weak_order, partial_order)
(compare_strong_order_fallback, compare_weak_order_fallback)
(compare_partial_order_fallback, __detail::__synth3way): Add
nodiscard attribute.
* testsuite/18_support/comparisons/categories/zero_neg.cc: Add
-Wno-unused-result to options.
This moves the same_as<decay_t<_Tp>, decay_t<_Up>> checks from the
[cmp.alg] function bodies into their constraints.
Also add a test for the compare_xxx_order_fallback algorithms.
libstdc++-v3/ChangeLog:
* libsupc++/compare (__decayed_same_as): New helper concept.
(strong_order, weak_order, partial_order): Constrain with new
concept instead of using static_assert.
(compare_strong_order_fallback, compare_weak_order_fallback)
(compare_partial_order_fallback): Likewise. Do not deduce return
types. Remove redundant if-constexpr checks.
* testsuite/18_support/comparisons/algorithms/fallback.cc: New test.
The proposed resolution for this library issue simplifies the
constraints for compare_three_way, ranges::equal_to, ranges::less etc.
so that they do not work with types which are convertible to pointers
but which fail to meet the usual syntactic requirements for the
comparisons.
This affects the example in PR libstdc++/93628 but doesn't fix the
problem described in that report.
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__eq_builtin_ptr_cmp): Remove.
(ranges::equal_to, ranges::not_equal_to): Do not constrain
with __eq_builtin_ptr_cmp.
(ranges::less, ranges::greater, ranges::less_equal)
(ranges::greater_equal): Do not constrain with
__less_builtin_ptr_cmp.
* libsupc++/compare (compare_three_way): Do not constrain with
__3way_builtin_ptr_cmp.
* testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc: Moved to...
* testsuite/18_support/comparisons/object/lwg3530.cc: ...here.
* testsuite/20_util/function_objects/range.cmp/lwg3530.cc: New test.
I thought I had implemented P1186R3, but apparently I didn't read it closely
enough to understand the point of the paper, namely that for a defaulted
operator<=>, if a member type doesn't have a viable operator<=>, we will use
its operator< and operator== if the defaulted operator has an specific
comparison category as its return type; the compiler can't guess if it
should be strong_ordering or something else, but the user can make that
choice explicit.
The libstdc++ test change was necessary because of the change in
genericize_spaceship from op0 > op1 to op1 < op0; this should be equivalent,
but isn't because of PR88173.
gcc/cp/ChangeLog:
PR c++/96299
* cp-tree.h (build_new_op): Add overload that omits some parms.
(genericize_spaceship): Add location_t parm.
* constexpr.c (cxx_eval_binary_expression): Pass it.
* cp-gimplify.c (genericize_spaceship): Pass it.
* method.c (genericize_spaceship): Handle class-type arguments.
(build_comparison_op): Fall back to op</== when appropriate.
gcc/testsuite/ChangeLog:
PR c++/96299
* g++.dg/cpp2a/spaceship-synth-neg2.C: Move error.
* g++.dg/cpp2a/spaceship-p1186.C: New test.
libstdc++-v3/ChangeLog:
PR c++/96299
* testsuite/18_support/comparisons/algorithms/partial_order.cc:
One more line needs to use VERIFY instead of static_assert.
libstdc++-v3/ChangeLog:
* testsuite/18_support/comparisons/algorithms/partial_order.cc:
Replace VERIFY with static_assert where the compiler now
allows it.
* testsuite/18_support/comparisons/algorithms/weak_order.cc:
Likewise.
Comparing a comparison category type to anything except a literal 0 is
undefined. This verifies that at least some misuses are diagnosed at
compile time.
* testsuite/18_support/comparisons/categories/zero_neg.cc: New test.
My "simplification" of std::compare_three_way's constraints in commit
f214ffb336 was incorrect, because
std::three_way_comparable_with imposes additional restrictions beyond
the <=> expression being valid.
* libsupc++/compare (compare_three_way): Fix constraint so that
BUILTIN-PTR-THREE-WAY does not require three_way_comparable_with.
* testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc:
New test.
LWG 3324 changed the [cmp.alg] types to use std::compare_three_way
instead of the <=> operator, but we were still using the old
specification. In order to make the existing tests pass the N::X type
needs to be equality comparable, so that three_way_comparable is
satisfied and compare_three_way can be used.
As part of this change I noticed that the compare_three_way call
operator was unconditionally noexcept, which is incorrect.
* libsupc++/compare (compare_three_way): Fix noexcept-specifier.
(strong_order, weak_order, partial_order): Replace uses of <=> with
compare_three_way function object (LWG 3324).
* testsuite/18_support/comparisons/algorithms/partial_order.cc: Add
equality operator so that X satisfies three_way_comparable.
* testsuite/18_support/comparisons/algorithms/strong_order.cc:
Likewise.
* testsuite/18_support/comparisons/algorithms/weak_order.cc: Likewise.
This reduces the size and alignment of all three comparison category
types to a single byte. The partial_ordering::_M_is_ordered flag is
replaced by the value 0x02 in the _M_value member.
This also optimizes conversion and comparison operators to avoid
conditional branches where possible, by comparing _M_value to constants
or using bitwise operations to correctly handle the unordered state.
* libsupc++/compare (__cmp_cat::type): Define typedef for underlying
type of enumerations and comparison category types.
(__cmp_cat::_Ord, __cmp_cat::_Ncmp): Add underlying type.
(__cmp_cat::_Ncmp::unordered): Change value to 2.
(partial_ordering::_M_value, weak_ordering::_M_value)
(strong_ordering::_M_value): Change type to __cmp_cat::type.
(partial_ordering::_M_is_ordered): Remove data member.
(partial_ordering): Use second bit of _M_value for unordered. Adjust
comparison operators.
(weak_ordering::operator partial_ordering): Simplify to remove
branches.
(operator<=>(unspecified, weak_ordering)): Likewise.
(strong_ordering::operator partial_ordering): Likewise.
(strong_ordering::operator weak_ordering): Likewise.
(operator<=>(unspecified, strong_ordering)): Likewise.
* testsuite/18_support/comparisons/categories/partialord.cc: New test.
* testsuite/18_support/comparisons/categories/strongord.cc: New test.
* testsuite/18_support/comparisons/categories/weakord.cc: New test.
The __3way_builtin_ptr_cmp concept can use three_way_comparable_with to
check whether <=> is valid. Doing that makes it obvious that the
disjunction on compare_three_way::operator() is redundant, because
the second constraint subsumes the first.
The workaround for PR c++/91073 can also be removed as that bug is fixed
now.
* libsupc++/compare (__detail::__3way_builtin_ptr_cmp): Use
three_way_comparable_with.
(__detail::__3way_cmp_with): Remove workaround for fixed bug.
(compare_three_way::operator()): Remove redundant constraint from
requires-clause.
(__detail::_Synth3way::operator()): Use three_way_comparable_with
instead of workaround.
* testsuite/18_support/comparisons/object/93479.cc: Prune extra
output due to simplified constraints on compare_three_way::operator().
Currently types that cannot be compared using <=> but which are
convertible to pointers will be compared by converting to pointers
first. They should not be comparable.
PR libstdc++/93479
* libsupc++/compare (__3way_builtin_ptr_cmp): Require <=> to be valid.
* testsuite/18_support/comparisons/object/93479.cc: New test.
This is incomplete because std::strong_order doesn't support
floating-point types.
The partial_order and weak_order tests use VERIFY instead of
static_assert because of PR 92431.
* libsupc++/compare (strong_order, weak_order, partial_order)
(compare_strong_order_fallback, compare_weak_order_fallback)
(compare_partial_order_fallback): Define customization point objects
for C++20.
* testsuite/18_support/comparisons/algorithms/partial_order.cc: New
test.
* testsuite/18_support/comparisons/algorithms/strong_order.cc: New
test.
* testsuite/18_support/comparisons/algorithms/weak_order.cc: New test.
From-SVN: r278149
