rust/compiler/rustc_ast_pretty/src/pprust/state, branch 1.78.0

AST: Refactor type alias where clauses

2024-02-29T16:18:40+00:00

Add `ErrorGuaranteed` to `ast::ExprKind::Err`

2024-02-25T21:24:31+00:00

Add `ast::ExprKind::Dummy`

2024-02-25T21:22:09+00:00

Delegation implementation: step 1

2024-01-12T11:11:16+00:00

Auto merge of #119105 - dtolnay:paren, r=WaffleLapkin

2023-12-27T21:27:26+00:00

Fix parenthesization of subexprs containing statement boundary This PR fixes a multitude of false negatives and false positives in the AST pretty printer's parenthesis insertion related to statement boundaries — statements which terminate unexpectedly early if there aren't parentheses. Without this fix, the AST pretty printer (including both `stringify!` and `rustc -Zunpretty=expanded`) is prone to producing output which is not syntactically valid Rust. Invalid output is problematic because it means Rustfmt is unable to parse the output of `cargo expand`, for example, causing friction by forcing someone trying to debug a macro into reading poorly formatted code. I believe the set of bugs fixed in this PR account for the most prevalent reason that `cargo expand` produces invalid output in real-world usage. Fixes #98790. ## False negatives The following is a correct program — `cargo check` succeeds. ```rust macro_rules! m { ($e:expr) => { match () { _ => $e } }; } fn main() { m!({ 1 } - 1); } ``` But `rustc -Zunpretty=expanded main.rs` produces output that is invalid Rust syntax, because parenthesization is needed and not being done by the pretty printer. ```rust fn main() { match () { _ => { 1 } - 1, }; } ``` Piping this expanded code to rustfmt, it fails to parse. ```console error: unexpected `,` in pattern --> :1:38 | 1 | fn main() { match () { _ => { 1 } - 1, }; } | ^ | help: try adding parentheses to match on a tuple... | 1 | fn main() { match () { _ => { 1 } (- 1,) }; } | + + help: ...or a vertical bar to match on multiple alternatives | 1 | fn main() { match () { _ => { 1 } - 1 | }; } | ~~~~~ ``` Fixed output after this PR: ```rust fn main() { match () { _ => ({ 1 }) - 1, }; } ``` ## False positives Less problematic, but worth fixing (just like #118726). ```rust fn main() { let _ = match () { _ => 1 } - 1; } ``` Output of `rustc -Zunpretty=expanded lib.rs` before this PR. There is no reason parentheses would need to be inserted there. ```rust fn main() { let _ = (match () { _ => 1, }) - 1; } ``` After this PR: ```rust fn main() { let _ = match () { _ => 1, } - 1; } ``` ## Alternatives considered In this PR I opted to parenthesize only the leading subexpression causing the statement boundary, rather than the entire statement. Example: ```rust macro_rules! m { ($e:expr) => { $e }; } fn main() { m!(loop { break [1]; }[0] - 1); } ``` This PR produces the following pretty-printed contents for fn main: ```rust (loop { break [1]; })[0] - 1; ``` A different equally correct output would be: ```rust (loop { break [1]; }[0] - 1); ``` I chose the one I did because it is the *only* approach used by handwritten code in the standard library and compiler. There are 4 places where parenthesization is being used to prevent a statement boundary, and in all 4, the developer has chosen to parenthesize the smallest subexpression rather than the whole statement: https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_codegen_cranelift/example/alloc_system.rs#L102 https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_parse/src/errors.rs#L1021-L1029 https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/future/poll_fn.rs#L151 https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/ops/range.rs#L824-L828

Rollup merge of #119169 - fmease:pretty-yeet-syntactic-cruft, r=compiler-errors

2023-12-22T18:01:26+00:00

Rid the AST & HIR pretty printer of cruft Found while working on #119163. For `trait Trait: ?Sized {}` (semantically malformed), we currently output `trait Trait for ? Sized {}` (sic!) / `trait Trait for ? Sized { }` (sic!) if `-Zunpretty=expanded` / `-Zunpretty=hir` is passed. `trait Tr for Sized? {}` (#15521) and later also `trait Tr for ?Sized {}` (I guess, #20194) is former Rust syntax. Hence I'm removing these outdated branches. ~~This will conflict with #119163, therefore marking this PR as blocked.~~ Rebased

Auto merge of #118847 - eholk:for-await, r=compiler-errors

2023-12-22T14:17:10+00:00

Add support for `for await` loops This adds support for `for await` loops. This includes parsing, desugaring in AST->HIR lowering, and adding some support functions to the library. Given a loop like: ```rust for await i in iter { ... } ``` this is desugared to something like: ```rust let mut iter = iter.into_async_iter(); while let Some(i) = loop { match core::pin::Pin::new(&mut iter).poll_next(cx) { Poll::Ready(i) => break i, Poll::Pending => yield, } } { ... } ``` This PR also adds a basic `IntoAsyncIterator` trait. This is partly for symmetry with the way `Iterator` and `IntoIterator` work. The other reason is that for async iterators it's helpful to have a place apart from the data structure being iterated over to store state. `IntoAsyncIterator` gives us a good place to do this. I've gated this feature behind `async_for_loop` and opened #118898 as the feature tracking issue. r? `@compiler-errors`

Rid the AST & HIR pretty printers of syntactic cruft

2023-12-22T13:32:40+00:00

Auto merge of #119163 - fmease:refactor-ast-trait-bound-modifiers, r=compiler-errors

2023-12-22T02:00:55+00:00

Refactor AST trait bound modifiers Instead of having two types to represent trait bound modifiers in the parser / the AST (`parser::ty::BoundModifiers` & `ast::TraitBoundModifier`), only to map one to the other later, just use `parser::ty::BoundModifiers` (moved & renamed to `ast::TraitBoundModifiers`). The struct type is more extensible and easier to deal with (see [here](https://github.com/rust-lang/rust/pull/119099/files#r1430749981) and [here](https://github.com/rust-lang/rust/pull/119099/files#r1430752116) for context) since it more closely models what it represents: A compound of two kinds of modifiers, constness and polarity. Modeling this as an enum (the now removed `ast::TraitBoundModifier`) meant one had to add a new variant per *combination* of modifier kind, which simply isn't scalable and which lead to a lot of explicit non-DRY matches. NB: `hir::TraitBoundModifier` being an enum is fine since HIR doesn't need to worry representing invalid modifier kind combinations as those get rejected during AST validation thereby immensely cutting down the number of possibilities.

Refactor AST trait bound modifiers

2023-12-20T18:39:46+00:00