summary refs log tree commit diff
path: root/src/test/ui/parser
AgeCommit message (Collapse)AuthorLines
2020-12-25Auto merge of #80296 - ↵bors-12/+5
wesleywiser:revert_missing_fragment_specifier_hard_error, r=Mark-Simulacrum Revert missing fragment specifier hard error Closes #76605 Reopens #40107 r? `@Mark-Simulacrum`
2020-12-25Rollup merge of #80160 - diondokter:move_async_fix, r=davidtwcoDylan DPC-0/+29
Implemented a compiler diagnostic for move async mistake Fixes #79694 First time contributing, so I hope I'm doing everything right. (If not, please correct me!) This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it. Checked code: ```rust fn main() { move async { }; } ``` Previous output: ```txt PS C:\Repos\move_async_test> cargo build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: expected one of `|` or `||`, found keyword `async` --> src\main.rs:2:10 | 2 | move async { }; | ^^^^^ expected one of `|` or `||` error: aborting due to previous error error: could not compile `move_async_test` ``` New output: ```txt PS C:\Repos\move_async_test> cargo +dev build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: the order of `move` and `async` is incorrect --> src\main.rs:2:13 | 2 | let _ = move async { }; | ^^^^^^^^^^ | help: try switching the order | 2 | let _ = async move { }; | ^^^^^^^^^^ error: aborting due to previous error error: could not compile `move_async_test` ``` Is there a file/module where these kind of things are tested? Would love some feedback 😄
2020-12-22Revert "Promote missing_fragment_specifier to hard error"Wesley Wiser-12/+5
This reverts commit 02eae432e7476a0686633a8c2b7cb1d5aab1bd2c.
2020-12-21Implemented a compiler diagnostic for move async mistakeDion Dokter-0/+29
Ran the tidy check Following the diagnostic guide better Diagnostic generation is now relegated to its own function in the diagnostics module. Added tests Fixed the ui test
2020-12-19Auto merge of #77035 - mibac138:fn-fat-arrow-return, r=davidtwcobors-8/+44
Gracefully handle mistyping -> as => in function return type Fixes #77019
2020-12-10Rollup merge of #79851 - camelid:better-error-for-default-fn, r=davidtwcoTyler Mandry-12/+12
Clarify the 'default is only allowed on...' error Code like impl Foo { default fn foo() {} } will trigger the error error: `default` is only allowed on items in `impl` definitions --> src/lib.rs:5:5 | 5 | default fn foo() {} | -------^^^^^^^^^ | | | `default` because of this but that's very confusing! I *did* put it on an item in an impl! So this commit changes the message to error: `default` is only allowed on items in trait impls --> src/lib.rs:5:5 | 5 | default fn foo() {} | -------^^^^^^^^^ | | | `default` because of this
2020-12-09Accept arbitrary expressions in key-value attributes at parse timeVadim Petrochenkov-3/+3
2020-12-08Clarify the 'default is only allowed on...' errorCamelid-12/+12
Code like impl Foo { default fn foo() {} } will trigger the error error: `default` is only allowed on items in `impl` definitions --> src/lib.rs:5:5 | 5 | default fn foo() {} | -------^^^^^^^^^ | | | `default` because of this but that's very confusing! I *did* put it on an item in an impl! So this commit changes the message to error: `default` is only allowed on items in trait impls --> src/lib.rs:5:5 | 5 | default fn foo() {} | -------^^^^^^^^^ | | | `default` because of this
2020-12-04Fix UI tests for 'const expression' changeRyan Levick-3/+3
2020-12-03Gracefully handle confusing -> with : in function return typemibac138-8/+44
2020-11-30Auto merge of #79329 - camelid:int-lit-suffix-error, r=davidtwcobors-9/+9
Update error to reflect that integer literals can have float suffixes For example, `1` is parsed as an integer literal, but it can be turned into a float with the suffix `f32`. Now the error calls them "numeric literals" and notes that you can add a float suffix since they can be either integers or floats.
2020-11-27Update error to reflect that integer literals can have float suffixesCamelid-9/+9
For example, `1` is parsed as an integer literal, but it can be turned into a float with the suffix `f32`. Now the error calls them "numeric literals" and notes that you can add a float suffix since they can be either integers or floats.
2020-11-27Auto merge of #79266 - b-naber:gat_trait_path_parser, r=petrochenkovbors-10/+10
Generic Associated Types in Trait Paths - Ast part The Ast part of https://github.com/rust-lang/rust/pull/78978 r? `@petrochenkov`
2020-11-25add testsb-naber-10/+10
2020-11-25Auto merge of #79336 - camelid:rename-feature-oibit-to-auto, r=oli-obkbors-1/+1
Rename `optin_builtin_traits` to `auto_traits` They were originally called "opt-in, built-in traits" (OIBITs), but people realized that the name was too confusing and a mouthful, and so they were renamed to just "auto traits". The feature flag's name wasn't updated, though, so that's what this PR does. There are some other spots in the compiler that still refer to OIBITs, but I don't think changing those now is worth it since they are internal and not particularly relevant to this PR. Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>. r? `@oli-obk` (feel free to re-assign if you're not the right reviewer for this)
2020-11-23Rename `optin_builtin_traits` to `auto_traits`Camelid-1/+1
They were originally called "opt-in, built-in traits" (OIBITs), but people realized that the name was too confusing and a mouthful, and so they were renamed to just "auto traits". The feature flag's name wasn't updated, though, so that's what this PR does. There are some other spots in the compiler that still refer to OIBITs, but I don't think changing those now is worth it since they are internal and not particularly relevant to this PR. Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
2020-11-22resolve: Do not put macros into `module.unexpanded_invocations` unless necessaryVadim Petrochenkov-6/+6
2020-11-17Fix ui tests for `fn`s with qualifiers in `extern` blocksThePuzzlemaker-21/+42
2020-11-16improve error message for const ty param mismatchBastian Kauschke-4/+0
2020-11-03rustc_ast: `visit_mac` -> `visit_mac_call`Vadim Petrochenkov-1/+1
2020-10-30Rollup merge of #78523 - estebank:fix-return-type-parse-regression, r=dtolnayYuki Okushi-4/+10
Revert invalid `fn` return type parsing change Revert one of the changes in #78379. Fix #78507.
2020-10-29Add regression testEsteban Küber-0/+6
2020-10-29Revert invalid `fn` return type parsing changeEsteban Küber-4/+4
Fix #78507.
2020-10-29Rollup merge of #78460 - varkor:turbofish-string-generic, r=lcnrYuki Okushi-6/+6
Adjust turbofish help message for const generics Types are no longer special. (This message arguably only makes sense with `min_const_generics` or more, but we'll be there soon.) r? @lcnr
2020-10-28Adjust turbofish help message for const genericsvarkor-6/+6
2020-10-28Rollup merge of #78379 - estebank:fn-signature-parse, r=varkorDylan DPC-19/+30
Tweak invalid `fn` header and body parsing * Rely on regular "expected"/"found" parser error for `fn`, fix #77115 * Recover empty `fn` bodies when encountering `}` * Recover trailing `>` in return types * Recover from non-type in array type `[<BAD TOKEN>; LEN]`
2020-10-25Tweak invalid `fn` header and body parsingEsteban Küber-10/+9
* Recover empty `fn` bodies when encountering `}` * Recover trailing `>` in return types * Recover from non-type in array type `[<BAD TOKEN>; LEN]`
2020-10-26Use ? in core/std macrosTaiki Endo-1/+1
2020-10-25Rely on regular "expected"/"found" parser error for `fn`Esteban Küber-13/+25
2020-10-22Bless testsSantiago Pastorino-2/+2
2020-10-17Auto merge of #77124 - spastorino:const-exprs-rfc-2920, r=oli-obkbors-2/+2
Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`
2020-10-16Add inline const testsSantiago Pastorino-30/+0
2020-10-16Parse inline const patternsSantiago Pastorino-2/+22
2020-10-16Parse inline const expressionsSantiago Pastorino-0/+10
2020-10-17Suggest minimal subset features in `incomplete_features` lintYuki Okushi-0/+3
2020-10-15fix off-by-one in parameter spansAndy Russell-34/+34
2020-10-11rustc_parse: More precise spans for `tuple.0.0`Vadim Petrochenkov-5/+5
2020-10-07Detect blocks that could be struct expr bodiesEsteban Küber-0/+56
This approach lives exclusively in the parser, so struct expr bodies that are syntactically correct on their own but are otherwise incorrect will still emit confusing errors, like in the following case: ```rust fn foo() -> Foo { bar: Vec::new() } ``` ``` error[E0425]: cannot find value `bar` in this scope --> src/file.rs:5:5 | 5 | bar: Vec::new() | ^^^ expecting a type here because of type ascription error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> src/file.rs:5:15 | 5 | bar: Vec::new() | ^^^^^ only `Fn` traits may use parentheses error[E0107]: wrong number of type arguments: expected 1, found 0 --> src/file.rs:5:10 | 5 | bar: Vec::new() | ^^^^^^^^^^ expected 1 type argument ``` If that field had a trailing comma, that would be a parse error and it would trigger the new, more targetted, error: ``` error: struct literal body without path --> file.rs:4:17 | 4 | fn foo() -> Foo { | _________________^ 5 | | bar: Vec::new(), 6 | | } | |_^ | help: you might have forgotten to add the struct literal inside the block | 4 | fn foo() -> Foo { Path { 5 | bar: Vec::new(), 6 | } } | ``` Partially address last part of #34255.
2020-10-06Fix tests from rebaseMatthew Jasper-0/+1
2020-10-05Fix span for unicode escape suggestion.Eric Huss-3/+3
2020-10-02Rollup merge of #77444 - estebank:pat-field-label, r=davidtwcoJonas Schievink-4/+10
Fix span for incorrect pattern field and add label Address #73750.
2020-10-02Fix span for incorrect pattern field and add labelEsteban Küber-4/+10
2020-09-29`delay_span_bug` if const-checking an `async` functionDylan MacKenzie-47/+20
This errors during AST lowering. Any errors we emit here are just noise.
2020-09-26`char` not charvarkor-24/+24
2020-09-22Bless testsDylan MacKenzie-20/+47
2020-09-15improve diagnostics for lifetime after `&mut`SNCPlay42-0/+74
2020-09-10Syntactically permit unsafety on modsDavid Tolnay-0/+55
2020-09-09Rollup merge of #75984 - kornelski:typeormodule, r=matthewjasperTyler Mandry-6/+6
Improve unresolved use error message "use of undeclared type or module `foo`" doesn't mention that it could be a crate. This error can happen when users forget to add a dependency to `Cargo.toml`, so I think it's important to mention that it could be a missing crate. I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter, and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.
2020-09-03Auto merge of #73996 - da-x:short-unique-paths, r=petrochenkovbors-9/+9
diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310, and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed, and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions, it's rather simple logic, and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path to the last component. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable from anywhere.
2020-09-02Auto merge of #76160 - scileo:format-recovery, r=petrochenkovbors-2/+2
Improve recovery on malformed format call The token following a format expression should be a comma. However, when it is replaced with a similar token (such as a dot), then the corresponding error is emitted, but the token is treated as a comma, and the parsing step continues. r? @petrochenkov
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 23:44:40 +0000