about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser/mod.rs
AgeCommit message (Collapse)AuthorLines
2022-09-01Always import all tracing macros for the entire crate instead of piecemeal ↵Oli Scherer-1/+0
by module
2022-08-31Fix a bunch of typoDezhi Wu-1/+1
This PR will fix some typos detected by [typos]. I only picked the ones I was sure were spelling errors to fix, mostly in the comments. [typos]: https://github.com/crate-ci/typos
2022-08-23Remove the symbol from `ast::LitKind::Err`.Nicholas Nethercote-1/+1
Because it's never used meaningfully.
2022-08-15Simplify attribute handling in `parse_bottom_expr`.Nicholas Nethercote-2/+6
`Parser::parse_bottom_expr` currently constructs an empty `attrs` and then passes it to a large number of other functions. This makes the code harder to read than it should be, because it's not clear that many `attrs` arguments are always empty. This commit removes `attrs` and the passing, simplifying a lot of functions. The commit also renames `Parser::mk_expr` (which takes an `attrs` argument) as `mk_expr_with_attrs`, and introduces a new `mk_expr` which creates an expression with no attributes, which is the more common case.
2022-08-09Stringify non-shorthand visibility correctlyJacob Pratt-2/+10
2022-08-02Rollup merge of #100011 - compiler-errors:let-chain-restriction, r=fee1-deadMatthias Krüger-5/+2
Use Parser's `restrictions` instead of `let_expr_allowed` This also means that the `ALLOW_LET` flag is reset properly for subexpressions, so we can properly deny things like `a && (b && let c = d)`. Also the parser is a tiny bit smaller now. It doesn't reject _all_ bad `let` expr usages, just a bit more. cc `@c410-f3r`
2022-08-01Use expr parse restrictions for let expr parsingMichael Goulet-5/+2
2022-07-29Remove `TreeAndSpacing`.Nicholas Nethercote-18/+22
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-02ast: Add span to `Extern`Nixon Enraght-Moony-1/+10
2022-06-29Rollup merge of #98668 - TaKO8Ki:avoid-many-&str-to-string-conversions, ↵Matthias Krüger-7/+4
r=Dylan-DPC Avoid some `&str` to `String` conversions with `MultiSpan::push_span_label` This patch removes some`&str` to `String` conversions with `MultiSpan::push_span_label`.
2022-06-29avoid many `&str` to `String` conversions with `MultiSpan::push_span_label`Takayuki Maeda-7/+4
2022-06-25[rustc_parse] Forbid lets in certain placesCaio-1/+5
2022-06-14Rollup merge of #95211 - terrarier2111:improve-parser, r=compiler-errorsYuki Okushi-0/+16
Improve parser diagnostics This pr fixes https://github.com/rust-lang/rust/issues/93867 and contains a couple of diagnostics related changes to the parser. Here is a short list with some of the changes: - don't suggest the same thing that is the current token - suggest removing the current token if the following token is one of the suggestions (maybe incorrect) - tell the user to put a type or lifetime after where if there is none (as a warning) - reduce the amount of tokens suggested (via the new eat_noexpect and check_noexpect methods) If any of these changes are undesirable, i can remove them, thanks!
2022-06-13remove unnecessary `to_string` and `String::new`Takayuki Maeda-1/+1
2022-06-12Improves parser diagnostics, fixes #93867threadexception-0/+16
2022-05-21Merge crate and restricted visibilitiesJacob Pratt-18/+6
2022-05-21Remove feature: `crate` visibility modifierJacob Pratt-20/+4
2022-05-20Remove `crate` visibility usage in compilerJacob Pratt-1/+1
2022-05-11ast: Introduce some traits to get AST node properties genericallyVadim Petrochenkov-3/+3
And use them to avoid constructing some artificial `Nonterminal` tokens during expansion
2022-05-04Auto merge of #96546 - nnethercote:overhaul-MacArgs, r=petrochenkovbors-10/+3
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-10/+3
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-04-29errors: `span_suggestion` takes `impl ToString`David Wood-2/+2
Change `span_suggestion` (and variants) to take `impl ToString` rather than `String` for the suggested code, as this simplifies the requirements on the diagnostic derive. Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-28rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter`Vadim Petrochenkov-26/+26
2022-04-27Avoid producing `NoDelim` values in `TokenCursorFrame`.Nicholas Nethercote-21/+13
2022-04-21Introduced `Cursor::next_with_spacing_ref`.Nicholas Nethercote-5/+5
This lets us clone just the parts within a `TokenTree` that need cloning, rather than the entire thing. This is a surprisingly large performance win, up to 4% on `async-std-1.10.0`.
2022-04-21Produce `CloseDelim` and pop the stack at the same time.Nicholas Nethercote-27/+34
This makes `CloseDelim` handling more like `OpenDelim` handling, which produces `OpenDelim` and pushes the stack at the same time. It requires some adjustment to `parse_token_tree` now that we don't remain within the frame after getting the `CloseDelim`.
2022-04-21Avoid some tuple destructuring.Nicholas Nethercote-5/+7
Surprisingly, this is a non-trivial performance win.
2022-04-20Remove `Eof` sanity check in `Parser::inlined_bump_with`.Nicholas Nethercote-6/+0
A Google search of the error message fails to return any relevant resuts, suggesting this has never occurred in practice. And removeing it reduces instruction counts by up to 2% on some benchmarks.
2022-04-20Only record `fallback_span` when necessary.Nicholas Nethercote-1/+1
2022-04-20Remove the loop from `Parser::bump()`.Nicholas Nethercote-29/+34
The loop is there to handle a `NoDelim` open/close token. This commit changes `TokenCursor::inlined_next` so it never returns such a token. This is a performance win because the conditional test in `bump()` is removed. If the parser needs changing in the future to handle `NoDelim` tokens, then `inlined_next()` can easily be changed to return them.
2022-04-20Remove `TokenCursorFrame::open_delim`.Nicholas Nethercote-20/+5
Because it's now always true.
2022-04-20Use `true` for `open_delim`/`close_delim` in one spot.Nicholas Nethercote-2/+2
The `DelimToken` here is `NoDelim`, which means the returned delim tokens will just be ignored by `Parser::bump()`. This commit changes things so the delim tokens won't be returned.
2022-04-20Add a size assertion for `Parser`.Nicholas Nethercote-0/+5
2022-04-20Move desugaring code into its own function.Nicholas Nethercote-67/+60
It's not hot, so shouldn't be within the always inlined part.
2022-04-19Handle `Delimited` opening immediately.Nicholas Nethercote-1/+3
Instead of letting the next iteration of the loop handle it.
2022-04-19Add {open,close}_delim arguments to `TokenCursorFrame::new()`.Nicholas Nethercote-12/+13
This will facilitate the change in the next commit. `boolean` arguments aren't great, but the function is only used in three places within this one file.
2022-04-19Rearrange `TokenCursor::inlined_next()`.Nicholas Nethercote-17/+20
In particular, avoid wrapping a token within `TokenTree::Token` and then immediately matching it and returning the token within. Just return the token immediately.
2022-04-19Merge `TokenCursor::{next,next_desugared}`.Nicholas Nethercote-74/+65
And likewise for the inlined variants. I did this for simplicity, but interesting it was a performance win as well.
2022-04-19Inline and remove `Parser::next_tok()`.Nicholas Nethercote-32/+26
It has a single call site.
2022-04-19Inline and remove `TokenTree::{open_tt,close_tt}`.Nicholas Nethercote-2/+2
They both have a single call site.
2022-04-16Rollup merge of #94985 - dtolnay:constattr, r=pnkfelixDylan DPC-2/+2
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-07Shrink `Nonterminal`.Nicholas Nethercote-1/+1
By heap allocating the argument within `NtPath`, `NtVis`, and `NtStmt`. This slightly reduces cumulative and peak allocation amounts, most notably on `deep-vector`.
2022-04-05span: move `MultiSpan`David Wood-2/+2
`MultiSpan` contains labels, which are more complicated with the introduction of diagnostic translation and will use types from `rustc_errors` - however, `rustc_errors` depends on `rustc_span` so `rustc_span` cannot use types like `DiagnosticMessage` without dependency cycles. Introduce a new `rustc_error_messages` crate that can contain `DiagnosticMessage` and `MultiSpan`. Signed-off-by: David Wood <david.wood@huawei.com>
2022-03-30Spellchecking compiler commentsYuri Astrakhan-1/+1
This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.
2022-03-28Remove `Nonterminal::NtTT`.Nicholas Nethercote-1/+7
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-22Split `TokenCursor::{next,next_desugared}` into inlined and non-inlined halves.Nicholas Nethercote-5/+18
2022-03-22Split `Parser::bump_with` into inlined and non-inlined halves.Nicholas Nethercote-2/+9
The call site within `Parser::bump` is hot. Also add an inline annotation to `Parser::next_tok`. It was already being inlined by the compiler; this just makes sure that continues.
2022-03-15Parse inner attributes on inline const blockDavid Tolnay-2/+2
2022-03-02rename ErrorReported -> ErrorGuaranteedmark-3/+5
2022-02-28Rollup merge of #94445 - c410-f3r:more-let-chains, r=cjgillotMatthias Krüger-5/+5
4 - Make more use of `let_chains` Continuation of #94376. cc #53667