summary refs log tree commit diff
path: root/compiler/rustc_ast_pretty/src
AgeCommit message (Collapse)AuthorLines
2022-10-27Revert "Do not consider method call receiver as an argument in AST."Michael Goulet-9/+5
This reverts commit 970184528718d7c10579cac7b7e7e66ef2e2a3f5.
2022-09-14make `mk_attr_id` part of `ParseSess`SparrowLii-2/+4
2022-09-06Auto merge of #101241 - camsteffen:refactor-binding-annotations, r=cjgillotbors-16/+10
`BindingAnnotation` refactor * `ast::BindingMode` is deleted and replaced with `hir::BindingAnnotation` (which is moved to `ast`) * `BindingAnnotation` is changed from an enum to a tuple struct e.g. `BindingAnnotation(ByRef::No, Mutability::Mut)` * Associated constants added for convenience `BindingAnnotation::{NONE, REF, MUT, REF_MUT}` One goal is to make it more clear that `BindingAnnotation` merely represents syntax `ref mut` and not the actual binding mode. This was especially confusing since we had `ast::BindingMode`->`hir::BindingAnnotation`->`thir::BindingMode`. I wish there were more symmetry between `ByRef` and `Mutability` (variant) naming (maybe `Mutable::Yes`?), and I also don't love how long the name `BindingAnnotation` is, but this seems like the best compromise. Ideas welcome.
2022-09-03Fix global_asm macro pretty printingMichael Goulet-0/+2
2022-09-02Refactor and re-use BindingAnnotationCameron Steffen-16/+10
2022-08-18Add diagnostic translation lints to crates that don't emit them5225225-0/+2
2022-08-17Rollup merge of #100018 - nnethercote:clean-up-LitKind, r=petrochenkovMatthias Krüger-1/+1
Clean up `LitKind` r? ``@petrochenkov``
2022-08-16Rename some things related to literals.Nicholas Nethercote-1/+1
- Rename `ast::Lit::token` as `ast::Lit::token_lit`, because its type is `token::Lit`, which is not a token. (This has been confusing me for a long time.) reasonable because we have an `ast::token::Lit` inside an `ast::Lit`. - Rename `LitKind::{from,to}_lit_token` as `LitKind::{from,to}_token_lit`, to match the above change and `token::Lit`.
2022-08-16Shrink `ast::Attribute`.Nicholas Nethercote-2/+2
2022-08-11Rollup merge of #100350 - jhpratt:stringify-vis, r=cjgillotMatthias Krüger-2/+2
Stringify non-shorthand visibility correctly This makes `stringify!(pub(in crate))` evaluate to `pub(in crate)` rather than `pub(crate)`, matching the behavior before the `crate` shorthand was removed. Further, this changes `stringify!(pub(in super))` to evaluate to `pub(in super)` rather than the current `pub(super)`. If the latter is not desired (it is _technically_ breaking), it can be undone. Fixes #99981 `@rustbot` label +C-bug +regression-from-stable-to-beta +T-compiler
2022-08-10Do not consider method call receiver as an argument in AST.Camille GILLOT-5/+9
2022-08-09Stringify non-shorthand visibility correctlyJacob Pratt-2/+2
2022-08-04Enable unused_parens for match armswcampbell-1/+1
2022-07-29Remove `TreeAndSpacing`.Nicholas Nethercote-5/+5
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is not quite right. `Spacing` makes sense for `TokenTree::Token`, but does not make sense for `TokenTree::Delimited`, because a `TokenTree::Delimited` cannot be joined with another `TokenTree`. This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`, changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the `TreeAndSpacing` typedef. The commit removes these two impls: - `impl From<TokenTree> for TokenStream` - `impl From<TokenTree> for TreeAndSpacing` These were useful, but also resulted in code with many `.into()` calls that was hard to read, particularly for anyone not highly familiar with the relevant types. This commit makes some other changes to compensate: - `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`. - `TokenStream::token_{alone,joint}()` are added. - `TokenStream::delimited` is added. This results in things like this: ```rust TokenTree::token(token::Semi, stmt.span).into() ``` changing to this: ```rust TokenStream::token_alone(token::Semi, stmt.span) ``` This makes the type of the result, and its spacing, clearer. These changes also simplifies `Cursor` and `CursorRef`, because they no longer need to distinguish between `next` and `next_with_spacing`.
2022-07-12Parse closure bindersMaybe Waffle-0/+11
This is first step in implementing RFC 3216. - Parse `for<'a>` before closures in ast - Error in lowering - Add `closure_lifetime_binder` feature
2022-07-02ast: Add span to `Extern`Nixon Enraght-Moony-2/+2
2022-06-16Fix pretty printing of empty type bound lists in where-clauseDavid Tolnay-49/+72
2022-06-02Revert #96682.Nicholas Nethercote-18/+5
The change was "Show invisible delimiters (within comments) when pretty printing". It's useful to show these delimiters, but is a breaking change for some proc macros. Fixes #97608.
2022-05-23Rollup merge of #97254 - jhpratt:remove-crate-vis, r=cjgillotDylan DPC-5/+1
Remove feature: `crate` visibility modifier FCP completed in #53120.
2022-05-22rustc_parse: Move AST -> TokenStream conversion logic to `rustc_ast`Vadim Petrochenkov-31/+1
2022-05-21Merge crate and restricted visibilitiesJacob Pratt-2/+1
2022-05-21Remove feature: `crate` visibility modifierJacob Pratt-4/+1
2022-05-20Remove `crate` visibility usage in compilerJacob Pratt-35/+39
2022-05-18use `CursorRef` more, to not to clone `Tree`sklensy-2/+2
2022-05-11ast: Introduce some traits to get AST node properties genericallyVadim Petrochenkov-3/+43
And use them to avoid constructing some artificial `Nonterminal` tokens during expansion
2022-05-07Auto merge of #96094 - Elliot-Roberts:fix_doctests, r=compiler-errorsbors-5/+5
Begin fixing all the broken doctests in `compiler/` Begins to fix #95994. All of them pass now but 24 of them I've marked with `ignore HELP (<explanation>)` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are. There are also a few that I marked `ignore` that could maybe be made to work but seem less important. Each `ignore` has a rough "reason" for ignoring after it parentheses, with - `(pseudo-rust)` meaning "mostly rust-like but contains foreign syntax" - `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type), or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy. - `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting, like MIR. - `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup. Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo, there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful. I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else, I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool
2022-05-05Rollup merge of #96682 - nnethercote:show-invisible-delims, r=petrochenkovMatthias Krüger-5/+18
Show invisible delimeters (within comments) when pretty printing. Because invisible syntax is really hard to work with! r? `@petrochenkov`
2022-05-05Rollup merge of #96628 - joshtriplett:stabilize-then-some, r=m-ou-seYuki Okushi-1/+0
Stabilize `bool::then_some` FCP completed in https://github.com/rust-lang/rust/issues/80967
2022-05-04Auto merge of #96546 - nnethercote:overhaul-MacArgs, r=petrochenkovbors-8/+20
Overhaul `MacArgs` Motivation: - Clarify some code that I found hard to understand. - Eliminate one use of three places where `TokenKind::Interpolated` values are created. r? `@petrochenkov`
2022-05-05Overhaul `MacArgs::Eq`.Nicholas Nethercote-3/+14
The value in `MacArgs::Eq` is currently represented as a `Token`. Because of `TokenKind::Interpolated`, `Token` can be either a token or an arbitrary AST fragment. In practice, a `MacArgs::Eq` starts out as a literal or macro call AST fragment, and then is later lowered to a literal token. But this is very non-obvious. `Token` is a much more general type than what is needed. This commit restricts things, by introducing a new type `MacArgsEqKind` that is either an AST expression (pre-lowering) or an AST literal (post-lowering). The downside is that the code is a bit more verbose in a few places. The benefit is that makes it much clearer what the possibilities are (though also shorter in some other places). Also, it removes one use of `TokenKind::Interpolated`, taking us a step closer to removing that variant, which will let us make `Token` impl `Copy` and remove many "handle Interpolated" code paths in the parser. Things to note: - Error messages have improved. Messages like this: ``` unexpected token: `"bug" + "found"` ``` now say "unexpected expression", which makes more sense. Although arbitrary expressions can exist within tokens thanks to `TokenKind::Interpolated`, that's not obvious to anyone who doesn't know compiler internals. - In `parse_mac_args_common`, we no longer need to collect tokens for the value expression.
2022-05-04Stabilize `bool::then_some`Josh Triplett-1/+0
2022-05-04Show invisible delimeters (within comments) when pretty printing.Nicholas Nethercote-5/+18
2022-05-02fix most compiler/ doctestsElliot Roberts-5/+5
2022-04-30Add `do yeet` expressions to allow experimentation in nightlyScott McMurray-1/+13
Using an obviously-placeholder syntax. An RFC would still be needed before this could have any chance at stabilization, and it might be removed at any point. But I'd really like to have it in nightly at least to ensure it works well with try_trait_v2, especially as we refactor the traits.
2022-04-29Tweak `print_attr_item`.Nicholas Nethercote-7/+8
This commit rearranges the `match`. The new code avoids testing for `MacArgs::Eq` twice, at the cost of repeating the `self.print_path()` call. I think this is worthwhile because it puts the `match` in a more standard and readable form.
2022-04-28rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter`Vadim Petrochenkov-13/+15
2022-04-27Avoid producing `NoDelim` values in `MacArgs::delim()`.Nicholas Nethercote-18/+20
2022-04-16Rollup merge of #94985 - dtolnay:constattr, r=pnkfelixDylan DPC-4/+15
Parse inner attributes on inline const block According to https://github.com/rust-lang/rust/pull/84414#issuecomment-826150936, inner attributes are intended to be supported *"in all containers for statements (or some subset of statements)"*. This PR adds inner attribute parsing and pretty-printing for inline const blocks (https://github.com/rust-lang/rust/issues/76001), which contain statements just like an unsafe block or a loop body. ```rust let _ = const { #![allow(...)] let x = (); x }; ```
2022-04-14Reimplement lowering of sym operands for asm! so that it also works with ↵Amanieu d'Antras-2/+6
global_asm!
2022-03-28Remove `Nonterminal::NtTT`.Nicholas Nethercote-1/+0
It's only needed for macro expansion, not as a general element in the AST. This commit removes it, adds `NtOrTt` for the parser and macro expansion cases, and renames the variants in `NamedMatch` to better match the new type.
2022-03-15Parse inner attributes on inline const blockDavid Tolnay-4/+15
2022-03-05Change syntax for TyAlias where clausesJack Huey-4/+34
2022-02-07Pretty print ItemKind::Use in rustfmt styleDavid Tolnay-15/+39
2022-02-03Change struct expr pretty printing to match rustfmt styleDavid Tolnay-31/+83
2022-02-03Support offsetting the most recent breakDavid Tolnay-0/+6
2022-02-03Change pp indent to signed to allow negative indentsDavid Tolnay-9/+8
2022-02-03Add trailing comma supportDavid Tolnay-7/+27
2022-02-03Rollup merge of #93515 - dtolnay:convenience, r=davidtwcoYuki Okushi-75/+78
Factor convenience functions out of main printer implementation The pretty printer in rustc_ast_pretty has a section of methods commented "Convenience functions to talk to the printer". This PR pulls those out to a separate module. This leaves pp.rs with only the minimal API that is core to the pretty printing algorithm. I found this separation to be helpful in https://github.com/dtolnay/prettyplease because it makes clear when changes are adding some fundamental new capability to the pretty printer algorithm vs just making it more convenient to call some already existing functionality.
2022-01-31Factor convenience functions out of main printer implementationDavid Tolnay-75/+78
2022-01-31Allow any line to have at least 60 charsDavid Tolnay-1/+4