| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This test currently fails (as expected).
--- stderr -------------------------------
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (1 + 1)
AFTER: #[attr] 1 + 1
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (1 as T)
AFTER: #[attr] 1 as T
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (x = 1)
AFTER: #[attr] x = 1
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (x += 1)
AFTER: #[attr] x += 1
------------------------------------------
|
|
|
|
avoid `&mut P<T>` in `visit_expr` etc methods
trying a different way than rust-lang/rust#141636
r? ghost
|
|
This test currently fails (as expected).
--- stderr -------------------------------
Pretty-printer lost necessary parentheses
BEFORE: (#[attr] loop {}).field
AFTER: #[attr] loop {}.field
------------------------------------------
|
|
Implement asymmetrical precedence for closures and jumps
I have been through a series of asymmetrical precedence designs in Syn, and finally have one that I like and is worth backporting into rustc. It is based on just 2 bits of state: `next_operator_can_begin_expr` and `next_operator_can_continue_expr`.
Asymmetrical precedence is the thing that enables `(return 1) + 1` to require parentheses while `1 + return 1` does not, despite `+` always having stronger precedence than `return` [according to the Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence). This is facilitated by `next_operator_can_continue_expr`.
Relatedly, it is the thing that enables `(return) - 1` to require parentheses while `return + 1` does not, despite `+` and `-` having exactly the same precedence. This is facilitated by `next_operator_can_begin_expr`.
**Example:**
```rust
macro_rules! repro {
($e:expr) => {
$e - $e;
$e + $e;
};
}
fn main() {
repro!{return}
repro!{return 1}
}
```
`-Zunpretty=expanded` **Before:**
```console
fn main() {
(return) - (return);
(return) + (return);
(return 1) - (return 1);
(return 1) + (return 1);
}
```
**After:**
```console
fn main() {
(return) - return;
return + return;
(return 1) - return 1;
(return 1) + return 1;
}
```
|
|
|
|
`visit_clobber` is not really useful except for one niche purpose
involving generic code. We should just use the replace logic where we
can.
|
|
|
|
Skip parenthesis around tuple struct field calls
The pretty-printer previously did not distinguish between named vs unnamed fields when printing a function call containing a struct field. It would print the call as `(self.fun)()` for a named field which is correct, and `(self.0)()` for an unnamed field which is redundant.
This PR changes function calls of tuple struct fields to print without parens.
**Before:**
```rust
struct Tuple(fn());
fn main() {
let tuple = Tuple(|| {});
(tuple.0)();
}
```
**After:**
```rust
struct Tuple(fn());
fn main() {
let tuple = Tuple(|| {});
tuple.0();
}
```
|
|
|
|
|
|
|
|
|
|
Detect invalid exprs in parser used by pretty-printer tests
This PR fixes a bug in https://github.com/rust-lang/rust/pull/133730 inherited from https://github.com/rust-lang/rust/pull/43742. Before this fix, the test might silently only operate on a prefix of some of the test cases in this table:
https://github.com/rust-lang/rust/blob/13170cd787cb733ed24842ee825bcbd98dc01476/tests/ui-fulldeps/pprust-parenthesis-insertion.rs#L57
For example, adding the test case `1 .. 2 .. 3` (a syntactically invalid expression) into the table would unexpectedly succeed the test instead of crashing at this unwrap:
https://github.com/rust-lang/rust/blob/13170cd787cb733ed24842ee825bcbd98dc01476/tests/ui-fulldeps/pprust-parenthesis-insertion.rs#L199-L200
because `parse_expr` would successfully parse just `1 .. 2` and disregard the last `.. 3`.
This PR adds a check that `parse_expr` reaches `Eof`, ensuring all the test cases actually test the whole expression they look like they are supposed to.
|
|
|
|
Support pretty-printing `dyn*` trait objects
- Tracking issue: https://github.com/rust-lang/rust/issues/102425
|
|
|
|
|
|
|
|
|
|
left-associative
|
|
|
|
Precedence improvements: closures and jumps
This PR fixes some cases where rustc's pretty printers would redundantly parenthesize expressions that didn't need it.
<table>
<tr><th>Before</th><th>After</th></tr>
<tr><td><code>return (|x: i32| x)</code></td><td><code>return |x: i32| x</code></td></tr>
<tr><td><code>(|| -> &mut () { std::process::abort() }).clone()</code></td><td><code>|| -> &mut () { std::process::abort() }.clone()</code></td></tr>
<tr><td><code>(continue) + 1</code></td><td><code>continue + 1</code></td></tr>
</table>
Tested by `echo "fn main() { let _ = $AFTER; }" | rustc -Zunpretty=expanded /dev/stdin`.
The pretty-printer aims to render the syntax tree as it actually exists in rustc, as faithfully as possible, in Rust syntax. It can insert parentheses where forced by Rust's grammar in order to preserve the meaning of a macro-generated syntax tree, for example in the case of `a * $rhs` where $rhs is `b + c`. But for any expression parsed from source code, without a macro involved, there should never be a reason for inserting additional parentheses not present in the original.
For closures and jumps (return, break, continue, yield, do yeet, become) the unneeded parentheses came from the precedence of some of these expressions being misidentified. In the same order as the table above:
- Jumps and closures are supposed to have equal precedence. The [Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence) says so, and in Syn they do. There is no Rust syntax that would require making a precedence distinction between jumps and closures. But in rustc these were previously 2 distinct levels with the closure being lower, hence the parentheses around a closure inside a jump (but not a jump inside a closure).
- When a closure is written with an explicit return type, the grammar [requires](https://doc.rust-lang.org/1.83.0/reference/expressions/closure-expr.html) that the closure body consists of exactly one block expression, not any other arbitrary expression as usual for closures. Parsing of the closure body does not continue after the block expression. So in `|| { 0 }.clone()` the clone is inside the closure body and applies to `{ 0 }`, whereas in `|| -> _ { 0 }.clone()` the clone is outside and applies to the closure as a whole.
- Continue never needs parentheses. It was previously marked as having the lowest possible precedence but it should have been the highest, next to paths and loops and function calls, not next to jumps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
