about summary refs log tree commit diff
path: root/compiler/rustc_parse/src
AgeCommit message (Collapse)AuthorLines
2023-11-26Use `rustc_fluent_macro::fluent_messages!` directly.Nicholas Nethercote-2/+1
Currently we always do this: ``` use rustc_fluent_macro::fluent_messages; ... fluent_messages! { "./example.ftl" } ``` But there is no need, we can just do this everywhere: ``` rustc_fluent_macro::fluent_messages! { "./example.ftl" } ``` which is shorter.
2023-11-26Avoid need for `{D,Subd}iagnosticMessage` imports.Nicholas Nethercote-1/+0
The `fluent_messages!` macro produces uses of `crate::{D,Subd}iagnosticMessage`, which means that every crate using the macro must have this import: ``` use rustc_errors::{DiagnosticMessage, SubdiagnosticMessage}; ``` This commit changes the macro to instead use `rustc_errors::{D,Subd}iagnosticMessage`, which avoids the need for the imports.
2023-11-24Add `Span` to `TraitBoundModifier`Deadbeef-1/+1
2023-11-21Fix `clippy::needless_borrow` in the compilerNilstrieb-20/+20
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`. Then I had to remove a few unnecessary parens and muts that were exposed now.
2023-11-19Rollup merge of #117988 - estebank:issue-106020, r=cjgillotMichael Goulet-0/+110
Handle attempts to have multiple `cfg`d tail expressions When encountering code that seems like it might be trying to have multiple tail expressions depending on `cfg` information, suggest alternatives that will success to parse. ```rust fn foo() -> String { #[cfg(feature = "validation")] [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() #[cfg(not(feature = "validation"))] String::new() } ``` ``` error: expected `;`, found `#` --> $DIR/multiple-tail-expr-behind-cfg.rs:5:64 | LL | #[cfg(feature = "validation")] | ------------------------------ only `;` terminated statements or tail expressions are allowed after this attribute LL | [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() | ^ expected `;` here LL | #[cfg(not(feature = "validation"))] | - unexpected token | help: add `;` here | LL | [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>(); | + help: alternatively, consider surrounding the expression with a block | LL | { [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() } | + + help: it seems like you are trying to provide different expressions depending on `cfg`, consider using `if cfg!(..)` | LL ~ if cfg!(feature = "validation") { LL ~ [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() LL ~ } else if cfg!(not(feature = "validation")) { LL ~ String::new() LL + } | ``` Fix #106020. r? `@oli-obk`
2023-11-19Rollup merge of #117891 - compiler-errors:recover-for-dyn, r=davidtwcoMichael Goulet-3/+57
Recover `dyn` and `impl` after `for<...>` Recover `dyn` and `impl` after `for<...>` in types. Reuses the logic for parsing bare trait objects, so it doesn't fix cases like `for<'a> dyn Trait + dyn Trait` or anything, but that seems somewhat of a different issue. Parsing recovery logic is a bit involved, but I couldn't find a way to simplify it. Fixes #117882
2023-11-19Don't sort `span_suggestions`, leave that to callerEsteban Küber-0/+1
2023-11-17Auto merge of #114292 - estebank:issue-71039, r=b-naberbors-27/+83
More detail when expecting expression but encountering bad macro argument On nested macro invocations where the same macro fragment changes fragment type from one to the next, point at the chain of invocations and at the macro fragment definition place, explaining that the change has occurred. Fix #71039. ``` error: expected expression, found pattern `1 + 1` --> $DIR/trace_faulty_macros.rs:49:37 | LL | (let $p:pat = $e:expr) => {test!(($p,$e))}; | ------- -- this is interpreted as expression, but it is expected to be pattern | | | this macro fragment matcher is expression ... LL | (($p:pat, $e:pat)) => {let $p = $e;}; | ------ ^^ expected expression | | | this macro fragment matcher is pattern ... LL | test!(let x = 1+1); | ------------------ | | | | | this is expected to be expression | in this macro invocation | = note: when forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type, not the underlying tokens = note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info) ```
2023-11-17Rollup merge of #117990 - estebank:issue-100825-part-deux, r=NilstriebMatthias Krüger-9/+8
Tweak error and move tests r? `@Nilstrieb` Split off #117565.
2023-11-17Rollup merge of #117892 - estebank:fat-arrow-typo, r=compiler-errorsMatthias Krüger-9/+10
Detect more `=>` typos Handle and recover `match expr { pat >= { arm } }`.
2023-11-16Fix code indentationEsteban Küber-2/+2
2023-11-16Handle attempts to have multiple `cfg`d tail expressionsEsteban Küber-0/+110
When encountering code that seems like it might be trying to have multiple tail expressions depending on `cfg` information, suggest alternatives that will success to parse. ```rust fn foo() -> String { #[cfg(feature = "validation")] [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() #[cfg(not(feature = "validation"))] String::new() } ``` ``` error: expected `;`, found `#` --> $DIR/multiple-tail-expr-behind-cfg.rs:5:64 | LL | #[cfg(feature = "validation")] | ------------------------------ only `;` terminated statements or tail expressions are allowed after this attribute LL | [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() | ^ expected `;` here LL | #[cfg(not(feature = "validation"))] | - unexpected token | help: add `;` here | LL | [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>(); | + help: alternatively, consider surrounding the expression with a block | LL | { [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() } | + + help: it seems like you are trying to provide different expressions depending on `cfg`, consider using `if cfg!(..)` | LL ~ if cfg!(feature = "validation") { LL ~ [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() LL ~ } else if cfg!(not(feature = "validation")) { LL ~ String::new() LL + } | ``` Fix #106020.
2023-11-16Smaller span for unnessary `mut` suggestionEsteban Küber-7/+6
2023-11-16More detail when expecting expression but encountering bad macro argumentEsteban Küber-27/+83
Partially address #71039.
2023-11-15Re-format code with new rustfmtMark Rousskov-10/+12
2023-11-14Fix some typoscui fliter-1/+1
Signed-off-by: cui fliter <imcusg@gmail.com>
2023-11-14Detect more `=>` typosEsteban Küber-9/+10
Handle and recover `match expr { pat >= { arm } }`.
2023-11-14Recover `dyn` and `impl` after `for<...>`Michael Goulet-3/+57
2023-11-13Auto merge of #117770 - sjwang05:issue-117766, r=estebank,TaKO8Kibors-20/+61
Catch stray `{` in let-chains Fixes #117766
2023-11-12Fix `is_keyword_ahead` visibilitysjwang05-1/+1
Co-authored-by: Takayuki Maeda <takoyaki0316@gmail.com>
2023-11-11Move unclosed delim errors to separate functionsjwang05-53/+58
2023-11-10Correctly handle while-let-chainssjwang05-2/+2
2023-11-09Catch an edge casesjwang05-1/+5
2023-11-09Catch stray { in let-chainssjwang05-1/+33
2023-11-09Suggest fix for ; within let-chainssjwang05-4/+20
2023-11-08Rollup merge of #117282 - clubby789:recover-wrong-function-header, r=TaKO8KiGuillaume Gomez-3/+37
Recover from incorrectly ordered/duplicated function keywords Fixes #115714
2023-11-07Auto merge of #117297 - clubby789:fn-trait-missing-paren, r=TaKO8Kibors-0/+40
Give a better diagnostic for missing parens in Fn* bounds Fixes #108109 It would be nice to try and recover here, but I'm not sure it's worth the effort, especially as the bounds on the recovered function would be incorrect.
2023-11-04fmtDinu Blanovschi-3/+1
2023-11-04feat(hir): Store the `Span` of the `move` keywordDinu Blanovschi-1/+4
2023-11-03Auto merge of #117507 - nnethercote:rustc_span, r=Nilstriebbors-10/+10
`rustc_span` cleanups Just some things I found while looking over this crate. r? `@oli-obk`
2023-11-02Minimize `pub` usage in `source_map.rs`.Nicholas Nethercote-10/+10
Most notably, this commit changes the `pub use crate::*;` in that file to `use crate::*;`. This requires a lot of `use` items in other crates to be adjusted, because everything defined within `rustc_span::*` was also available via `rustc_span::source_map::*`, which is bizarre. The commit also removes `SourceMap::span_to_relative_line_string`, which is unused.
2023-11-01Rollup merge of #117298 - clubby789:fn-missing-params, r=petrochenkovMatthias Krüger-0/+18
Recover from missing param list in function definitions Addresses the other issue mentioned in #108109
2023-11-01Auto merge of #117289 - estebank:issue-72298, r=cjgillotbors-1/+33
Account for `ref` and `mut` in the wrong place for pattern ident renaming If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code. Fix #72298.
2023-11-01Give a better diagnostic for missing parens in Fn* boundsclubby789-0/+40
2023-11-01Recover from missing param list in function definitionsclubby789-0/+18
2023-10-31Rollup merge of #116712 - estebank:issue-116252, r=petrochenkovMatthias Krüger-27/+63
When encountering unclosed delimiters during lexing, check for diff markers Fix #116252.
2023-10-30Talk about `gen fn` in diagnostics about `gen fn`Oli Scherer-3/+3
2023-10-30When encountering unclosed delimiters during parsing, check for diff markersEsteban Küber-27/+63
Fix #116252.
2023-10-30Account for `ref` and `mut` in the wrong place for pattern ident renamingEsteban Küber-1/+33
If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code. Fix #72298.
2023-10-29Auto merge of #116889 - MU001999:master, r=petrochenkovbors-0/+2
Eat close paren if capture_cfg to avoid unbalanced parens Fixes #116781
2023-10-29Auto merge of #116447 - oli-obk:gen_fn, r=compiler-errorsbors-13/+51
Implement `gen` blocks in the 2024 edition Coroutines tracking issue https://github.com/rust-lang/rust/issues/43122 `gen` block tracking issue https://github.com/rust-lang/rust/issues/117078 This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically. An example usage of `gen` blocks is ```rust fn foo() -> impl Iterator<Item = i32> { gen { yield 42; for i in 5..18 { if i.is_even() { continue } yield i * 2; } } } ``` The limitations (to be resolved) of the implementation are listed in the tracking issue
2023-10-28restore snapshot when parse_param_generalMu001999-0/+2
2023-10-27Recover from incorrectly ordered/duplicated function keywordsclubby789-3/+37
2023-10-27Rollup merge of #117212 - clubby789:fix-ternary-recover, r=compiler-errorsMatthias Krüger-13/+13
Properly restore snapshot when failing to recover parsing ternary If the recovery parsed an expression, then failed to eat a `:`, it would return `false` without restoring the snapshot. Fix this by always restoring the snapshot when returning `false`. Draft for now because I'd like to try and improve this recovery further. Fixes #117208
2023-10-27Handle `move` generatorsOli Scherer-11/+8
2023-10-27Feature gate `gen` blocks, even in 2024 editionOli Scherer-1/+2
2023-10-27Add gen blocks to ast and do some broken ast loweringOli Scherer-18/+14
2023-10-26Recover ternary expression as errorclubby789-9/+11
2023-10-26Properly restore snapshot when failing to recover parsing ternaryclubby789-4/+2
2023-10-26Reserve `gen` keyword for `gen {}` blocks and `gen fn` in 2024 editionOli Scherer-2/+46