about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser
AgeCommit message (Collapse)AuthorLines
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-24/+20
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the most common diagnostic level. It makes sense to do likewise for the closely-related (and much more widely used) `DiagnosticBuilder` type, letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just `DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many multi-line things becoming single line things.
2023-12-22Auto merge of #118847 - eholk:for-await, r=compiler-errorsbors-6/+15
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`
2023-12-22Auto merge of #119163 - fmease:refactor-ast-trait-bound-modifiers, ↵bors-49/+29
r=compiler-errors 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.
2023-12-22Auto merge of #119097 - nnethercote:fix-EmissionGuarantee, r=compiler-errorsbors-84/+76
Fix `EmissionGuarantee` There are some problems with the `DiagCtxt` API related to `EmissionGuarantee`. This PR fixes them. r? `@compiler-errors`
2023-12-20Rollup merge of #119145 - aDotInTheVoid:variantdata-struct-struct, ↵Matthias Krüger-5/+5
r=compiler-errors Give `VariantData::Struct` named fields, to clairfy `recovered`. Implements https://github.com/rust-lang/rust/pull/119121#discussion_r1431467066. Supersedes #119121 This way, it's clear what the bool fields means, instead of having to find where it's generated. Changes both ast and hir. r? `@compiler-errors`
2023-12-20Refactor AST trait bound modifiersLeón Orell Valerian Liehr-49/+29
2023-12-20Rollup merge of #118691 - chfogelman:improve-cstr-error, r=fmeaseMatthias Krüger-7/+29
Add check for possible CStr literals in pre-2021 Fixes [#118654](https://github.com/rust-lang/rust/issues/118654) Adds information to errors caused by possible CStr literals in pre-2021. The lexer separates `c"str"` into two tokens if the edition is less than 2021, which later causes an error when parsing. This error now has a more helpful message that directs them to information about editions. However, the user might also have written `c "str"` in a later edition, so to not confuse people who _are_ using a recent edition, I also added a note about whitespace. We could probably figure out exactly which scenario has been encountered by examining spans and editions, but I figured it would be better not to overcomplicate the creation of the error too much. This is my first code PR and I tried to follow existing conventions as much as possible, but I probably missed something, so let me know!
2023-12-19Add additional tests and update existing testsEric Holk-1/+2
2023-12-20Give `VariantData::Struct` named fields, to clairfy `recovered`.Alona Enraght-Moony-5/+5
2023-12-19Improve compiler error for c-strings in pre-2021Carter Hunt Fogelman-7/+29
2023-12-19Plumb awaitness of for loopsEric Holk-6/+14
2023-12-18Use `.into_diagnostic()` less.Nicholas Nethercote-84/+76
This commit replaces this pattern: ``` err.into_diagnostic(dcx) ``` with this pattern: ``` dcx.create_err(err) ``` in a lot of places. It's a little shorter, makes the error level explicit, avoids some `IntoDiagnostic` imports, and is a necessary prerequisite for the next commit which will add a `level` arg to `into_diagnostic`. This requires adding `track_caller` on `create_err` to avoid mucking up the output of `tests/ui/track-diagnostics/track4.rs`. It probably should have been there already.
2023-12-18Rename `Parser::span_diagnostic` as `Parser::dcx`.Nicholas Nethercote-42/+40
2023-12-18Rename `ParseSess::span_diagnostic` as `ParseSess::dcx`.Nicholas Nethercote-4/+4
2023-12-18Rename `Handler` as `DiagCtxt`.Nicholas Nethercote-3/+3
2023-12-15NFC don't convert types to identical typesMatthias Krüger-1/+1
2023-12-14Rollup merge of #118933 - nnethercote:cleanup-errors-even-more, ↵Jubilee-2/+2
r=compiler-errors Cleanup errors handlers even more A sequel to #118587. r? `@compiler-errors`
2023-12-15Change `msg: impl Into<String>` for bug diagnostics.Nicholas Nethercote-2/+2
To `msg: impl Into<DiagnosticMessage>`, like all the other diagnostics. For consistency.
2023-12-12Rollup merge of #118891 - compiler-errors:async-gen-blocks, r=eholkJubilee-9/+18
Actually parse async gen blocks correctly 1. I got the control flow in `parse_expr_bottom` messed up, and obviously forgot a test for `async gen`, so we weren't actually ever parsing it correctly. 2. I forgot to gate the span for `async gen {}`, so even if we did parse it, we wouldn't have correctly denied it in `cfg(FALSE)`. r? eholk
2023-12-12Actually parse async gen blocks correctlyMichael Goulet-9/+18
2023-12-12Don't gate the feature twiceNadrieril-1/+4
2023-12-12Correctly gate the parsing of match arms without bodyNadrieril-1/+6
2023-12-11Add spacing information to delimiters.Nicholas Nethercote-24/+27
This is an extension of the previous commit. It means the output of something like this: ``` stringify!(let a: Vec<u32> = vec![];) ``` goes from this: ``` let a: Vec<u32> = vec![] ; ``` With this PR, it now produces this string: ``` let a: Vec<u32> = vec![]; ```
2023-12-11Improve `print_tts` by changing `tokenstream::Spacing`.Nicholas Nethercote-5/+12
`tokenstream::Spacing` appears on all `TokenTree::Token` instances, both punct and non-punct. Its current usage: - `Joint` means "can join with the next token *and* that token is a punct". - `Alone` means "cannot join with the next token *or* can join with the next token but that token is not a punct". The fact that `Alone` is used for two different cases is awkward. This commit augments `tokenstream::Spacing` with a new variant `JointHidden`, resulting in: - `Joint` means "can join with the next token *and* that token is a punct". - `JointHidden` means "can join with the next token *and* that token is a not a punct". - `Alone` means "cannot join with the next token". This *drastically* improves the output of `print_tts`. For example, this: ``` stringify!(let a: Vec<u32> = vec![];) ``` currently produces this string: ``` let a : Vec < u32 > = vec! [] ; ``` With this PR, it now produces this string: ``` let a: Vec<u32> = vec![] ; ``` (The space after the `]` is because `TokenTree::Delimited` currently doesn't have spacing information. The subsequent commit fixes this.) The new `print_tts` doesn't replicate original code perfectly. E.g. multiple space characters will be condensed into a single space character. But it's much improved. `print_tts` still produces the old, uglier output for code produced by proc macros. Because we have to translate the generated code from `proc_macro::Spacing` to the more expressive `token::Spacing`, which results in too much `proc_macro::Along` usage and no `proc_macro::JointHidden` usage. So `space_between` still exists and is used by `print_tts` in conjunction with the `Spacing` field. This change will also help with the removal of `Token::Interpolated`. Currently interpolated tokens are pretty-printed nicely via AST pretty printing. `Token::Interpolated` removal will mean they get printed with `print_tts`. Without this change, that would result in much uglier output for code produced by decl macro expansions. With this change, AST pretty printing and `print_tts` produce similar results. The commit also tweaks the comments on `proc_macro::Spacing`. In particular, it refers to "compound tokens" rather than "multi-char operators" because lifetimes aren't operators.
2023-12-10remove redundant importssurechen-8/+1
detects redundant imports that can be eliminated. for #117772 : In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR.
2023-12-08Auto merge of #118420 - compiler-errors:async-gen, r=eholkbors-68/+85
Introduce support for `async gen` blocks I'm delighted to demonstrate that `async gen` block are not very difficult to support. They're simply coroutines that yield `Poll<Option<T>>` and return `()`. **This PR is WIP and in draft mode for now** -- I'm mostly putting it up to show folks that it's possible. This PR needs a lang-team experiment associated with it or possible an RFC, since I don't think it falls under the jurisdiction of the `gen` RFC that was recently authored by oli (https://github.com/rust-lang/rfcs/pull/3513, https://github.com/rust-lang/rust/issues/117078). ### Technical note on the pre-generator-transform yield type: The reason that the underlying coroutines yield `Poll<Option<T>>` and not `Poll<T>` (which would make more sense, IMO, for the pre-transformed coroutine), is because the `TransformVisitor` that is used to turn coroutines into built-in state machine functions would have to destructure and reconstruct the latter into the former, which requires at least inserting a new basic block (for a `switchInt` terminator, to match on the `Poll` discriminant). This does mean that the desugaring (at the `rustc_ast_lowering` level) of `async gen` blocks is a bit more involved. However, since we already need to intercept both `.await` and `yield` operators, I don't consider it much of a technical burden. r? `@ghost`
2023-12-08Support async gen fnMichael Goulet-56/+66
2023-12-08coro_kind -> coroutine_kindMichael Goulet-6/+6
2023-12-08Implement `async gen` blocksMichael Goulet-11/+18
2023-12-08Auto merge of #118527 - Nadrieril:never_patterns_parse, r=compiler-errorsbors-136/+155
never_patterns: Parse match arms with no body Never patterns are meant to signal unreachable cases, and thus don't take bodies: ```rust let ptr: *const Option<!> = ...; match *ptr { None => { foo(); } Some(!), } ``` This PR makes rustc accept the above, and enforces that an arm has a body xor is a never pattern. This affects parsing of match arms even with the feature off, so this is delicate. (Plus this is my first non-trivial change to the parser). ~~The last commit is optional; it introduces a bit of churn to allow the new suggestions to be machine-applicable. There may be a better solution? I'm not sure.~~ EDIT: I removed that commit r? `@compiler-errors`
2023-12-07Rollup merge of #116420 - bvanjoi:fix-116203, r=NilstriebMatthias Krüger-1/+3
discard invalid spans in external blocks Fixes #116203 This PR has discarded the invalid `const_span`, thereby making the format more neat. r? ``@Nilstrieb``
2023-12-06Auto merge of #118655 - compiler-errors:rollup-vrngyzn, r=compiler-errorsbors-10/+12
Rollup of 9 pull requests Successful merges: - #117793 (Update variable name to fix `unused_variables` warning) - #118123 (Add support for making lib features internal) - #118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always) - #118346 (Add `deeply_normalize_for_diagnostics`, use it in coherence) - #118350 (Simplify Default for tuples) - #118450 (Use OnceCell in cell module documentation) - #118585 (Fix parser ICE when recovering `dyn`/`impl` after `for<...>`) - #118587 (Cleanup error handlers some more) - #118642 (bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`) r? `@ghost` `@rustbot` modify labels: rollup
2023-12-05Rollup merge of #118585 - sjwang05:issue-118564, r=compiler-errorsMichael Goulet-10/+12
Fix parser ICE when recovering `dyn`/`impl` after `for<...>` Fixes #118564
2023-12-05Auto merge of #118457 - eholk:genfn, r=compiler-errorsbors-25/+55
Add support for `gen fn` This builds on #116447 to add support for `gen fn` functions. For the most part we follow the same approach as desugaring `async fn`, but replacing `Future` with `Iterator` and `async {}` with `gen {}` for the body. The version implemented here uses the return type of a `gen fn` as the yield type. For example: ```rust gen fn count_to_three() -> i32 { yield 1; yield 2; yield 3; } ``` In the future, I think we should experiment with a syntax like `gen fn count_to_three() yield i32 { ... }`, but that can go in another PR. cc `@oli-obk` `@compiler-errors`
2023-12-05Rollup merge of #117922 - estebank:unclosed-generics, r=b-naberMatthias Krüger-10/+35
Tweak unclosed generics errors Remove unnecessary span label for parse errors that already have a suggestion. Provide structured suggestion to close generics in more cases.
2023-12-04Address code review feedbackEric Holk-2/+2
2023-12-04Option<CoroutineKind>Eric Holk-27/+27
2023-12-04Merge Async and Gen into CoroutineKindEric Holk-25/+47
2023-12-04Make async gen fn an errorEric Holk-0/+6
2023-12-04gate gen fn behind gen_blocksEric Holk-0/+4
2023-12-04Lower return types for gen fn to impl IteratorEric Holk-4/+0
2023-12-04Add genness to FnHeaderEric Holk-2/+4
2023-12-04Fix parser ICE when recovering `dyn`/`impl` after `for<...>`sjwang05-10/+12
2023-12-03Detect attempts to expand a macro to a match arm againNadrieril-27/+18
Because a macro invocation can expand to a never pattern, we can't rule out a `arm!(),` arm at parse time. Instead we detect that case at expansion time, if the macro tries to output a pattern followed by `=>`.
2023-12-03Parse a pattern with no armNadrieril-109/+137
2023-12-03Auto merge of #118542 - chenyukang:yukang-fix-parser-ice-118531, r=cjgillotbors-12/+4
Fix parser ICE from attrs Fixes #118531, Fixes #118530.
2023-12-02Fix parser ICE from attrsyukang-12/+4
2023-12-02Use `Session::diagnostic` in more places.Nicholas Nethercote-40/+33
2023-12-02Rename `HandlerInner::delay_span_bug` as `HandlerInner::span_delayed_bug`.Nicholas Nethercote-2/+2
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
2023-12-01Tweak unclosed generics errorsEsteban Küber-10/+35
Remove unnecessary span label for parse errors that already have a suggestion. Provide structured suggestion to close generics in more cases.