summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser/stmt.rs
AgeCommit message (Collapse)AuthorLines
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-18/+12
2024-09-18Add suggestions for expressions in patternsLieselotte-2/+8
2024-08-24Rollup merge of #128524 - ↵Trevor Gross-0/+5
chenyukang:yukang-fix-127930-invalid-outer-style-sugg, r=cjgillot Don't suggest turning crate-level attributes into outer style Fixes #127930
2024-08-16Overhaul token collection.Nicholas Nethercote-17/+45
This commit does the following. - Renames `collect_tokens_trailing_token` as `collect_tokens`, because (a) it's annoying long, and (b) the `_trailing_token` bit is less accurate now that its types have changed. - In `collect_tokens`, adds a `Option<CollectPos>` argument and a `UsePreAttrPos` in the return type of `f`. These are used in `parse_expr_force_collect` (for vanilla expressions) and in `parse_stmt_without_recovery` (for two different cases of expression statements). Together these ensure are enough to fix all the problems with token collection and assoc expressions. The changes to the `stringify.rs` test demonstrate some of these. - Adds a new test. The code in this test was causing an assertion failure prior to this commit, due to an invalid `NodeRange`. The extra complexity is annoying, but necessary to fix the existing problems.
2024-08-16Convert a bool to `Trailing`.Nicholas Nethercote-6/+7
This pre-existing type is suitable for use with the return value of the `f` parameter in `collect_tokens_trailing_token`. The more descriptive name will be useful because the next commit will add another boolean value to the return value of `f`.
2024-08-14Use `impl PartialEq<TokenKind> for Token` more.Nicholas Nethercote-2/+2
This lets us compare a `Token` with a `TokenKind`. It's used a lot, but can be used even more, avoiding the need for some `.kind` uses.
2024-08-11Rollup merge of #128762 - fmease:use-more-slice-pats, r=compiler-errorsMatthias Krüger-3/+3
Use more slice patterns inside the compiler Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'. r? ghost
2024-08-09parser: ensure let stmt compound assignment removal suggestion respect ↵许杰友 Jieyou Xu (Joe)-2/+6
codepoint boundaries Previously we would try to issue a suggestion for `let x <op>= 1`, i.e. a compound assignment within a `let` binding, to remove the `<op>`. The suggestion code unfortunately incorrectly assumed that the `<op>` is an exactly-1-byte ASCII character, but this assumption is incorrect because we also recover Unicode-confusables like `➖=` as `-=`. In this example, the suggestion code used a `+ BytePos(1)` to calculate the span of the `<op>` codepoint that looks like `-` but the mult-byte Unicode look-alike would cause the suggested removal span to be inside a multi-byte codepoint boundary, triggering a codepoint boundary assertion. Issue: <https://github.com/rust-lang/rust/issues/128845>
2024-08-07Use more slice patterns inside the compilerLeón Orell Valerian Liehr-3/+3
2024-08-04don't suggest turning crate-level attributes into outer styleyukang-0/+5
2024-08-01Move a comment to a better spot.Nicholas Nethercote-2/+1
2024-07-31Remove `LhsExpr`.Nicholas Nethercote-4/+2
`parse_expr_assoc_with` has an awkward structure -- sometimes the lhs is already parsed. This commit splits the post-lhs part into a new method `parse_expr_assoc_rest_with`, which makes everything shorter and simpler.
2024-07-31Inline and remove `parse_local_mk`.Nicholas Nethercote-16/+6
It has a single use. This makes the `let` handling case in `parse_stmt_without_recovery` more similar to the statement path and statement expression cases.
2024-07-29Reformat `use` declarations.Nicholas Nethercote-17/+17
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-19Only check `force_collect` in `collect_tokens_trailing_token`.Nicholas Nethercote-16/+17
There are three places where we currently check `force_collect` and call `collect_tokens_no_attrs` for `ForceCollect::Yes` and a vanilla parsing function for `ForceCollect::No`. But we can instead just pass in `force_collect` and let `collect_tokens_trailing_token` do the appropriate thing.
2024-07-19Don't always force collect tokens in `recover_stmt_local_after_let`.Nicholas Nethercote-6/+9
Use a parameter to decide whether to force collect, as is done for the closely related `parse_local_mk` method.
2024-07-18Remove `TrailingToken`.Nicholas Nethercote-16/+4
It's used in `Parser::collect_tokens_trailing_token` to decide whether to capture a trailing token. But the callers actually know whether to capture a trailing token, so it's simpler for them to just pass in a bool. Also, the `TrailingToken::Gt` case was weird, because it didn't result in a trailing token being captured. It could have been subsumed by the `TrailingToken::MaybeComma` case, and it effectively is in the new code.
2024-07-17Rollup merge of #127806 - nnethercote:parser-improvements, r=spastorinoTrevor Gross-2/+2
Some parser improvements I was looking closely at attribute handling in the parser while debugging some issues relating to #124141, and found a few small improvements. ``@spastorino``
2024-07-16Reorder `Parser::parse_expr_dot_or_call_with` arguments.Nicholas Nethercote-2/+2
Put `attrs` before `e0` because that matches the order in the source code, where outer attributes appear before expressions.
2024-07-12Make parse error suggestions verbose and fix spansEsteban Küber-3/+5
Go over all structured parser suggestions and make them verbose style. When suggesting to add or remove delimiters, turn them into multiple suggestion parts.
2024-06-19Refactor `parse_expr_res`.Nicholas Nethercote-2/+2
This removes the final `Option<AttrWrapper>` argument.
2024-06-19Refactor `LhsExpr`.Nicholas Nethercote-8/+3
Combine `NotYetParsed` and `AttributesParsed` into a single variant, because (a) that reflects the structure of the code that consumes `LhsExpr`, and (b) because that variant will have the `Option` removed in a later commit.
2024-06-06Reduce `pub` exposure.Nicholas Nethercote-1/+1
2024-05-22Rollup merge of #125049 - dtolnay:castbrace, r=compiler-errorsLeón Orell Valerian Liehr-11/+17
Disallow cast with trailing braced macro in let-else This fixes an edge case I noticed while porting #118880 and #119062 to syn. Previously, rustc incorrectly accepted code such as: ```rust let foo = &std::ptr::null as &'static dyn std::ops::Fn() -> *const primitive! { 8 } else { return; }; ``` even though a right curl brace `}` directly before `else` in a `let...else` statement is not supposed to be valid syntax.
2024-05-17Clarify that the diff_marker is talking about version control systemardi-2/+2
conflicts specifically and a few more improvements.
2024-05-12Disallow cast with trailing braced macro in let-elseDavid Tolnay-11/+17
2024-05-09Add `ErrorGuaranteed` to `Recovered::Yes` and use it more.Nicholas Nethercote-6/+2
The starting point for this was identical comments on two different fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`: ``` // FIXME: investigate making this a `Option<ErrorGuaranteed>` recovered: bool ``` I tried that, and then found that I needed to add an `ErrorGuaranteed` to `Recovered::Yes`. Then I ended up using `Recovered` instead of `Option<ErrorGuaranteed>` for these two places and elsewhere, which required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`. This makes things more consistent, because `Recovered` is used in more places, and there are fewer uses of `bool` and `Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible to set `recovered` to `Recovered::Yes` without having emitted an error.
2024-03-21Use better variable names in some `maybe_whole!` calls.Nicholas Nethercote-2/+2
2024-03-21Use `maybe_whole!` to streamline `parse_stmt_without_recovery`.Nicholas Nethercote-11/+5
2024-03-14Rename `ast::StmtKind::Local` into `ast::StmtKind::Let`Guillaume Gomez-4/+4
2024-03-08Rollup merge of #119365 - nbdd0121:asm-goto, r=AmanieuMatthias Krüger-1/+1
Add asm goto support to `asm!` Tracking issue: #119364 This PR implements asm-goto support, using the syntax described in "future possibilities" section of [RFC2873](https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto). Currently I have only implemented the `label` part, not the `fallthrough` part (i.e. fallthrough is implicit). This doesn't reduce the expressive though, since you can use label-break to get arbitrary control flow or simply set a value and rely on jump threading optimisation to get the desired control flow. I can add that later if deemed necessary. r? ``@Amanieu`` cc ``@ojeda``
2024-03-06Cancel parsing ever made during recoveryclubby789-6/+10
2024-03-05Rename all `ParseSess` variables/fields/lifetimes as `psess`.Nicholas Nethercote-3/+3
Existing names for values of this type are `sess`, `parse_sess`, `parse_session`, and `ps`. `sess` is particularly annoying because that's also used for `Session` values, which are often co-located, and it can be difficult to know which type a value named `sess` refers to. (That annoyance is the main motivation for this change.) `psess` is nice and short, which is good for a name used this much. The commit also renames some `parse_sess_created` values as `psess_created`.
2024-03-01Detect more cases of `=` to `:` typoEsteban Küber-10/+64
When a `Local` is fully parsed, but not followed by a `;`, keep the `:` span arround and mention it. If the type could continue being parsed as an expression, suggest replacing the `:` with a `=`. ``` error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` --> file.rs:2:32 | 2 | let _: std::env::temp_dir().join("foo"); | - ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=` | | | while parsing the type for `_` | help: use `=` if you meant to assign ``` Fix #119665.
2024-02-28Rename `DiagnosticBuilder` as `Diag`.Nicholas Nethercote-5/+2
Much better! Note that this involves renaming (and updating the value of) `DIAGNOSTIC_BUILDER` in clippy.
2024-02-27Refactor `take_for_recovery` call sites.Nicholas Nethercote-2/+1
To make them more concise and similar to each other.
2024-02-25Add `ErrorGuaranteed` to `ast::ExprKind::Err`Lieselotte-28/+36
2024-02-24Add asm label support to AST and HIRGary Guo-1/+1
2024-02-20Add newtype for parser recoveryclubby789-3/+3
2024-02-20Add newtype for raw identsclubby789-1/+1
2024-01-18Suggest wrapping mac args in parens rather than the whole expressionMichael Goulet-4/+11
2024-01-08Make `DiagnosticBuilder::emit` consuming.Nicholas Nethercote-3/+3
This works for most of its call sites. This is nice, because `emit` very much makes sense as a consuming operation -- indeed, `DiagnosticBuilderState` exists to ensure no diagnostic is emitted twice, but it uses runtime checks. For the small number of call sites where a consuming emit doesn't work, the commit adds `DiagnosticBuilder::emit_without_consuming`. (This will be removed in subsequent commits.) Likewise, `emit_unless` becomes consuming. And `delay_as_bug` becomes consuming, while `delay_as_bug_without_consuming` is added (which will also be removed in subsequent commits.) All this requires significant changes to `DiagnosticBuilder`'s chaining methods. Currently `DiagnosticBuilder` method chaining uses a non-consuming `&mut self -> &mut Self` style, which allows chaining to be used when the chain ends in `emit()`, like so: ``` struct_err(msg).span(span).emit(); ``` But it doesn't work when producing a `DiagnosticBuilder` value, requiring this: ``` let mut err = self.struct_err(msg); err.span(span); err ``` This style of chaining won't work with consuming `emit` though. For that, we need to use to a `self -> Self` style. That also would allow `DiagnosticBuilder` production to be chained, e.g.: ``` self.struct_err(msg).span(span) ``` However, removing the `&mut self -> &mut Self` style would require that individual modifications of a `DiagnosticBuilder` go from this: ``` err.span(span); ``` to this: ``` err = err.span(span); ``` There are *many* such places. I have a high tolerance for tedious refactorings, but even I gave up after a long time trying to convert them all. Instead, this commit has it both ways: the existing `&mut self -> Self` chaining methods are kept, and new `self -> Self` chaining methods are added, all of which have a `_mv` suffix (short for "move"). Changes to the existing `forward!` macro lets this happen with very little additional boilerplate code. I chose to add the suffix to the new chaining methods rather than the existing ones, because the number of changes required is much smaller that way. This doubled chainging is a bit clumsy, but I think it is worthwhile because it allows a *lot* of good things to subsequently happen. In this commit, there are many `mut` qualifiers removed in places where diagnostics are emitted without being modified. In subsequent commits: - chaining can be used more, making the code more concise; - more use of chaining also permits the removal of redundant diagnostic APIs like `struct_err_with_code`, which can be replaced easily with `struct_err` + `code_mv`; - `emit_without_diagnostic` can be removed, which simplifies a lot of machinery, removing the need for `DiagnosticBuilderState`.
2023-12-24Remove `ParseSess` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-10/+11
Also add missing `#[track_caller]` attributes to `DiagCtxt` methods as necessary to keep tests working.
2023-12-24Remove `Parser` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-1/+1
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-2/+2
`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-11-29Rollup merge of #118394 - nnethercote:rm-hir-Ops, r=cjgillotMatthias Krüger-2/+2
Remove HIR opkinds `hir::BinOp`, `hir::BinOpKind`, and `hir::UnOp` are identical to `ast::BinOp`, `ast::BinOpKind`, and `ast::UnOp`, respectively. This seems silly, so this PR removes the HIR ones. (A re-export lets the AST ones be referred to using a `hir::` qualifier, which avoids renaming churn.) r? `@cjgillot`
2023-11-28Rename `BinOpKind::lazy` as `BinOpKind::is_lazy`.Nicholas Nethercote-1/+1
To match `BinOpKind::is_comparison` and `hir::BinOpKind::is_lazy`.
2023-11-28Rework `ast::BinOpKind::to_string` and `ast::UnOp::to_string`.Nicholas Nethercote-1/+1
- Rename them both `as_str`, which is the typical name for a function that returns a `&str`. (`to_string` is appropriate for functions returning `String` or maybe `Cow<'a, str>`.) - Change `UnOp::as_str` from an associated function (weird!) to a method. - Avoid needless `self` dereferences.
2023-11-27Change help message to make some sense in broader contextHirochika Matsumoto-1/+1
2023-11-27Address review feedbacksHirochika Matsumoto-16/+17
Also addressed merge conflicts upon rebasing.