about summary refs log tree commit diff
path: root/tests/ui/parser
AgeCommit message (Collapse)AuthorLines
2023-09-06Add explanatory note to 'expected item' errorGurinder Singh-0/+29
2023-09-06Auto merge of #115371 - matthewjasper:if-let-guard-parsing, r=cjgillotbors-2/+47
Make if let guard parsing consistent with normal guards - Add tests that struct expressions are not allowed in `if let` and `while let` (no change, consistent with `if` and `while`) - Allow struct expressions in `if let` guards (consistent with `if` guards). r? `@cjgillot` Closes #93817 cc #51114
2023-08-30Rollup merge of #114704 - bvanjoi:fix-114636, r=compiler-errorsMatthias Krüger-38/+44
parser: not insert dummy field in struct Fixes #114636 This PR eliminates the dummy field, initially introduced in #113999, thereby enabling unrestricted use of `ident.unwrap()`. A side effect of this action is that we can only report the error of the first macro invocation field within the struct node. An alternative solution might be giving a virtual name to the macro, but it appears more complex.(https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715). Furthermore, if you think https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715 is a better solution, feel free to close this PR.
2023-08-28Allow stuct literals in if let guardsMatthew Jasper-0/+3
This is consistent with normal match guards.
2023-08-28Add tests for struct literals in if let/while letMatthew Jasper-2/+44
2023-08-24Auto merge of #115131 - frank-king:feature/unnamed-fields-lite, r=petrochenkovbors-0/+72
Parse unnamed fields and anonymous structs or unions (no-recovery) It is part of #114782 which implements #49804. Only parse anonymous structs or unions in struct field definition positions. r? `@petrochenkov`
2023-08-24Parse unnamed fields and anonymous structs or unionsFrank King-0/+72
Anonymous structs or unions are only allowed in struct field definitions. Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
2023-08-21discard dummy field for macro invocation when parse structbohan-38/+44
2023-08-17Auto merge of #114802 - chenyukang:yukang-fix-114979-bad-parens-dyn, r=estebankbors-8/+8
Fix bad suggestion when wrong parentheses around a dyn trait Fixes #114797
2023-08-16Fix bad suggestion when wrong parentheses around a dyn traityukang-8/+8
2023-08-15Clean up some bad ui testing annotationsMichael Goulet-3/+8
2023-08-07relocate tests to pass tidydarklyspaced-0/+0
2023-08-07fix testsdarklyspaced-25/+2
2023-08-07test infra addeddarklyspaced-0/+38
2023-08-04Rollup merge of #113999 - Centri3:macro-arm-expand, r=wesleywiserMatthias Krüger-0/+172
Specify macro is invalid in certain contexts Adds a note when a macro is used where it really shouldn't be. Closes #113766
2023-08-03Rollup merge of #114300 - MU001999:fix/turbofish-pat, r=estebankMatthias Krüger-13/+32
Suggests turbofish in patterns Fixes #114112 r? ```@estebank```
2023-08-02Add test for enum with fieldsCatherine Flores-31/+53
2023-08-01Suggests turbofish in patternsMu001999-13/+32
2023-07-31parser: more friendly hints for handling `async move` in the 2015 editionbohan-0/+12
2023-07-29Auto merge of #114028 - Centri3:ternary-operator, r=compiler-errorsbors-0/+184
Gracefully handle ternary operator Fixes #112578 ~~May not be the best way to do this as it doesn't check for a single `:`, so it could perhaps appear even when the actual issue is just a missing semicolon. May not be the biggest deal, though?~~ Nevermind, got it working properly now ^^
2023-07-28Add UI tests for generic const itemsLeón Orell Valerian Liehr-0/+12
2023-07-25Remove unnecessary `maybe_ternary_lo` fieldCatherine Flores-19/+50
2023-07-25Gracefully handle missing ternary operatorCatherine Flores-0/+153
2023-07-24Recover from some macrosCatherine Flores-86/+88
2023-07-24Specify macro is invalid in certain contextsCatherine-0/+148
2023-07-22Support interpolated block for try and asyncMichael Goulet-0/+35
2023-07-11Lint against misplaced where-clauses on assoc tys in traitsLeón Orell Valerian Liehr-127/+0
2023-07-05Fix the issue of wrong diagnosis for extern pub fnyukang-0/+20
2023-07-04Detect extra space in keyword for better hintyukang-0/+0
2023-06-27Rollup merge of #112978 - compiler-errors:bad-block-sugg, r=davidtwcoMatthias Krüger-0/+16
Add suggestion for bad block fragment error Makes it a bit clearer how to fix this parser restriction
2023-06-27Rollup merge of #112518 - chenyukang:yukang-fix-112458, r=davidtwcoMatthias Krüger-0/+19
Detect actual span for getting unexpected token from parsing macros Fixes #112458
2023-06-23Add suggestion for bad block fragment errorMichael Goulet-0/+16
2023-06-15Handle interpolated literal errorsMichael Goulet-0/+18
2023-06-12Fix debug ICE for extern type with where clauses许杰友 Jieyou Xu (Joe)-1/+13
2023-06-11Detect actual span for getting unexpected token from parsing macrosyukang-0/+19
2023-06-11Rollup merge of #112498 - SamZhang3:rust-reference-link-update, r=NilstriebMatthias Krüger-6/+6
Update links to Rust Reference in diagnostic Instead of linking to the [old Rust Reference site](https://static.rust-lang.org/doc/master/reference.html#literals), which is severely outdated (Rust 1.17), link to the [current website](https://doc.rust-lang.org/stable/reference/expressions/literal-expr.html) in diagnostic about incorrect literals.
2023-06-10Use a better linkHankai Zhang-6/+6
2023-06-10Update links to Rust Reference page on literals in diagnosticHankai Zhang-6/+6
Instead of linking to the old Rust Reference site on static.rust-lang.org, link to the current website doc.rust-lang.org/stable/reference instead in diagnostic about incorrect literals.
2023-06-10reword the message to suggest surrounding with parenthesesyukang-5/+5
2023-06-10take care module name for suggesting surround the struct literal in parenthesesyukang-0/+78
2023-06-03Fix suggestion for matching struct with `..` on both ends许杰友 Jieyou Xu (Joe)-1/+66
2023-05-28Recover upon encountering mistyped `Const` in const param def许杰友 Jieyou Xu (Joe)-0/+62
2023-05-27Rollup merge of #111181 - bvanjoi:fix-issue-111148, r=davidtwcoMatthias Krüger-0/+10
fix(parse): return unpected when current token is EOF close https://github.com/rust-lang/rust/issues/111148 #111148 panic occurred because [FatalError.raise()](https://github.com/bvanjoi/rust/blob/master/compiler/rustc_parse/src/parser/mod.rs#LL540C3-L540C3) was encountered which caused by `Eof` and `Pound`(the last token) had same span, when parsing `#` in `fn a<<i<Y<w<>#`. <img width="825" alt="image" src="https://user-images.githubusercontent.com/30187863/236612589-9e2c6a0b-18cd-408c-b636-c12a51cbcf1c.png"> There are a few ways to solve this problem: - Change the action assign for [self.last_unexpected_token_span](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/diagnostics.rs#L592), for example, if current token is `Eof`, then return Error directly. - Avoid triggering the `FatalError` when the current token is `Eof`. I have chosen the second option because executing `expected_one_of_not_found` when the token is `Eof` but not in `ediable` seems reasonable.
2023-05-16Rollup merge of #111449 - compiler-errors:recover-impl-generics-correctly, ↵Nilstrieb-0/+14
r=Nilstrieb Recover `impl<T ?Sized>` correctly Fixes #111327 r? ````@Nilstrieb```` but you can re-roll Alternatively, happy to close this if we're okay with just saying "sorry #111327 is just a poor side-effect of parser ambiguity" 🤷
2023-05-16Rollup merge of #111428 - bvanjoi:fix-109250, r=NilstriebNilstrieb-6/+6
refactor(resolve): clean up the early error return caused by non-call closes https://github.com/rust-lang/rust/issues/109250 It seems no bad happened, r? ``@Nilstrieb``
2023-05-15Recover `impl<T ?Sized>` correctlyMichael Goulet-0/+14
2023-05-13fmtyukang-2/+1
2023-05-13Fix ice caused by shorthand fields in NoFieldsForFnCallyukang-0/+22
2023-05-13fix(parse): return unpected when current token is EOFbohan-0/+10
2023-05-10refactor(resolve): clean up the early error return caused by non-callbohan-6/+6
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 14:44:49 +0000