Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level

[dtolnay]

I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer).

As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as PREC_POSTFIX (field access, square bracket index, question mark, method call) and PREC_PAREN (loops, if, paths, literals).

There are a bunch of places that look at either prec < PREC_POSTFIX or prec >= PREC_POSTFIX. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another.

rust/compiler/rustc_ast/src/util/parser.rs

Lines 236 to 237 in d49994b

	pub const PREC_POSTFIX: i8 = 60;
	pub const PREC_PAREN: i8 = 99;

rust/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs

Line 2829 in d49994b

let close_paren = if expr.precedence().order() < PREC_POSTFIX {

rust/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs

Line 1290 in d49994b

let mut sugg = if expr.precedence().order() >= PREC_POSTFIX {

In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1.

There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. x.f() means a different thing than (x.f)(). But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax — you can tell because if it did, then x.f[0].f() wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level.

rust/compiler/rustc_ast_pretty/src/pprust/state/expr.rs

Lines 217 to 221 in d49994b

	fn print_expr_call(&mut self, func: &ast::Expr, args: &[P<ast::Expr>], fixup: FixupContext) {
	let prec = match func.kind {
	ast::ExprKind::Field(..) => parser::PREC_FORCE_PAREN,
	_ => parser::PREC_POSTFIX,
	};

[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

[dtolnay]

This line contains the only observable behavior change in this PR.

rust-lang/rust-clippy#12990 has a writeup of what this code is doing. It is using precedence of the parent expression of an expression x to decide whether it's possible to suggest replacing x by &x, or by (&x).

Precedence of the parent expression is the wrong thing for Clippy to be looking at in this code, and causes the false negatives reported in the link. This PR increases the number of cases which encounter that false negative in the short term, such as [x; 2], but does not make the issue harder to fix in Clippy.

[compiler-errors]

r? compiler-errors @bors r+

[bors]

📌 Commit 273447c has been approved by compiler-errors

It is now in the queue for this repository.