os-rust/compiler/rustc_ast
Matthias Krüger 709baaef13
Rollup merge of #126893 - dtolnay:prec, r=compiler-errors
Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level

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.

d49994b060/compiler/rustc_ast/src/util/parser.rs (L236-L237)

d49994b060/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L2829)

d49994b060/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L1290)

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 &mdash; 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.

d49994b060/compiler/rustc_ast_pretty/src/pprust/state/expr.rs (L217-L221)
2024-06-25 18:03:00 +02:00
..
src Rollup merge of #126893 - dtolnay:prec, r=compiler-errors 2024-06-25 18:03:00 +02:00
Cargo.toml Split rustc_type_ir to avoid rustc_ast from depending on it 2024-02-27 18:11:23 +00:00
README.md docs(rustc_ast): update crate descriptions 2021-11-02 21:11:17 -05:00

The rustc_ast crate contains those things concerned purely with syntax that is, the AST ("abstract syntax tree"), along with some definitions for tokens and token streams, data structures/traits for mutating ASTs, and shared definitions for other AST-related parts of the compiler (like the lexer and macro-expansion).

For more information about how these things work in rustc, see the rustc dev guide: