Inline ExprPrecedence::order into Expr::precedence

[dtolnay]

The representation of expression precedence in rustc_ast has been an obstacle to further improvements in the pretty-printer (continuing from #119105 and #119427).

Previously the operation of "does this expression have lower precedence than that one" (relevant for parenthesis insertion in macro-generated syntax trees) consisted of 3 steps:

1. Convert Expr to ExprPrecedence using .precedence()
2. Convert ExprPrecedence to i8 using .order()
3. Compare using <

As far as I can guess, the reason for the separation between precedence() and order() was so that both rustc_ast::Expr and rustc_hir::Expr could convert as straightforwardly as possible to the same ExprPrecedence enum, and then the more finicky logic performed by order could be present just once.

The mapping between Expr and ExprPrecedence was intended to be as straightforward as possible:

match self.kind {
    ExprKind::Closure(..) => ExprPrecedence::Closure,
    ...
}

although there were exceptions of both many-to-one, and one-to-many:

    ExprKind::Underscore => ExprPrecedence::Path,
    ExprKind::Path(..) => ExprPrecedence::Path,
    ...
    ExprKind::Match(_, _, MatchKind::Prefix) => ExprPrecedence::Match,
    ExprKind::Match(_, _, MatchKind::Postfix) => ExprPrecedence::PostfixMatch,

Where the nature of ExprPrecedence becomes problematic is when a single expression kind might be associated with multiple different precedence levels depending on context (outside the expression) and contents (inside the expression). For example consider what is the precedence of an ExprKind::Closure $closure. Well, on the left-hand side of a binary operator it would need parentheses in order to avoid the trailing binary operator being absorbed into the closure body: ($closure) + Rhs, so the precedence is something lower than that of +. But on the right-hand side of a binary operator, a closure is just a straightforward prefix expression like a unary op, which is a relatively high precedence level, higher than binops but lower than method calls: Lhs + $closure is fine without parens but ($closure).method() needs them. But as a third case, if the closure contains an explicit return type, then the precedence is an even higher level than that, never needing parenthesization even in a binop left-hand side or method call: || -> bool { false } + Rhs or || -> bool { false }.method().

You can see that trying to capture all of this resolution about expressions into ExprPrecedence violates the intention of ExprPrecedence being a straightforward one-to-one correspondence from each AST and HIR ExprKind variant. It would be possible to attempt that by doing stuff like ExprPrecedence::Closure(Side::Leading, ReturnType::No), but I don't foresee the original envisioned benefit of the precedence()/order() distinction being retained in this approach. Instead I want to move toward a model that Syn has been using successfully. In Syn, there is a Precedence enum but it differs from rustc in the following ways:

• There are relatively few variants compared to rustc's ExprPrecedence. For example there is no distinction at the precedence level between returns and closures, or between loops and method calls.

• We distinguish between leading and trailing precedence, taking into account an expression's context such as what token follows it (for various syntactic bail-outs in Rust's grammar, like ambiguities around break-with-value) and how it relates to operators from the surrounding syntax tree.

• There are no hardcoded mysterious integer quantities like rustc's PREC_CLOSURE = -40. All precedence comparisons are performed via PartialOrd on a C-like enum.

This PR is just a first step in these changes. As you can tell from Syn, I definitely think there is value in having a dedicated type to represent precedence, instead of what order() is doing with i8. But that is a whole separate adventure because rustc_ast doesn't even agree consistently on i8 being the type for precedence order; AssocOp::precedence instead uses usize and there are casts in both directions. It is likely that a type called ExprPrecedence will re-appear, but it will look substantially different from the one that existed before this PR.

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[fmease]

This makes sense, thank you! Looking forward to all the follow-up PRs :)

[fmease]

@bors r+ rollup (refactoring)

[bors]

📌 Commit e5f1555 has been approved by fmease

It is now in the queue for this repository.