This is a work-in-progress attempt to add operator<=> rewriting, including the required changes to overload resolution.
The rewritten expression is represented with the newly added AST node CXXRewrittenExpr. This node contains two sub-statements. The first is a "dummy" expression representing the syntactic form of the initial expression, where the input expressions are represented using OpaqueValueExpr. The second represents the rewritten expression, the input expressions are used here directly (ie are not wrapped in OpaqueValueExprs).
As currently implemented, rewritten and synthesized candidates are only partially checked for viability when they're added to the overload candidates (the conversion sequence from the argument type -> parameter type is checked, but nothing else). This can lead non-viable candidates being selected or causing ambiguity when final overload resolution is attempted.
The solution implemented in this patch is to fully build "potentially viable" candidates if they are selected or cause ambiguity. If building the candidate fails, it is marked as non-viable, and a new best viable function is computed.
The problem with this approach is that it's expensive and potentially wasteful. For example, if overload resolution results in ambiguity with N rewritten candidates with the same partial ordering, then all N candidates are fully built, and those results potentially thrown away.
For builtin candidates this can be avoided by separating out the bits of CheckBinaryOperands which compute it's result type from the bits which actually build the expression and convert the arguments. Once we know the return type of the builtin, we can deduce if the comparison category type can be used in the expression 0 @ <comp-category> without much effect.
However, for non-builtin overloads of operator<=> (which don't return a comparison category type), it seems non-trivial to check that 0 @ <result> is valid without actually attempting to build the overloaded binary operator.
This should have a name ending Expr.