| Age | Commit message (Collapse) | Author | Lines |
|
commits
Revert "review comment: Remove AST AnonTy"
This reverts commit 020cca8d36cb678e3ddc2ead41364be314d19e93.
Revert "Ensure macros are not affected"
This reverts commit 12d18e403139eeeeb339e8611b2bed4910864edb.
Revert "Emit fewer errors on patterns with possible type ascription"
This reverts commit c847a01a3b1f620c4fdb98c75805033e768975d1.
Revert "Teach parser to understand fake anonymous enum syntax"
This reverts commit 2d824206655bfb26cb5eed43490ee396542b153e.
|
|
|
|
#[derive(Subdiagnostic)] does not allow multiple subdiagnostics on one
variant, as in NonItemInItemListSub::Other.
|
|
|
|
This is required in order to support translatable diagnostics.
|
|
|
|
The check previously matched this, and suggested adding a missing
`struct`:
pub Foo(...):
It was probably intended to match this instead (semicolon instead of
colon):
pub Foo(...);
|
|
|
|
|
|
Make the "extra if in let...else block" hint a suggestion
Changes the hint to a suggestion, suggested in #107213.
r? ```@estebank```
|
|
Improve enum checks
Some light refactoring.
|
|
Fix invalid float literal suggestions when recovering an integer
Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
r? nnethercote
|
|
|
|
Only suggest adding a zero to integers with a preceding dot when the change will
result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
|
|
|
|
|
|
|
|
|
|
Recover from more const arguments that are not wrapped in curly braces
Recover from some array, borrow, tuple & arithmetic expressions in const argument positions that lack curly braces and provide a suggestion to fix the issue continuing where #92884 left off. Examples of such expressions: `[]`, `[0]`, `[1, 2]`, `[0; 0xff]`, `&9`, `("", 0)` and `(1 + 2) * 3` (we previously did not recover from them).
I am not entirely happy with my current solution because the code that recovers from `[0]` (coinciding with a malformed slice type) and `[0; 0]` (coinciding with a malformed array type) is quite fragile as the aforementioned snippets are actually successfully parsed as types by `parse_ty` since it itself already recovers from them (returning `[⟨error⟩]` and `[⟨error⟩; 0]` respectively) meaning I have to manually look for `TyKind::Err`s and construct a separate diagnostic for the suggestion to attach to (thereby emitting two diagnostics in total).
Fixes #81698.
`@rustbot` label A-diagnostics
r? diagnostics
|
|
|
|
Teach parser to understand fake anonymous enum syntax
Parse `Ty | OtherTy` in function argument and return types.
Parse type ascription in top level patterns.
Minimally address #100741.
|
|
Adds an additional hint to failures where we encounter an else keyword
while we're parsing an if-let block.
This is likely that the user has accidentally mixed if-let and let...else
together.
|
|
|
|
Recover labels written as identifiers
This adds recovery for `break label expr` and `continue label`, as well as a test for `break label`.
|
|
Remove double spaces after dots in comments
Most of the comments do not have double spaces, so I assume these are typos.
|
|
|
|
make error emitted on `impl &Trait` nicer
Fixes #106694
Turned out to be simpler than I thought, also added UI test.
Before: ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9bda53271ef3a8886793cf427b8cea91))
```text
error: expected one of `:`, ``@`,` or `|`, found `)`
--> src/main.rs:2:22
|
2 | fn foo(_: impl &Trait) {}
| ^ expected one of `:`, ``@`,` or `|`
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a parameter name, give it a type
|
2 | fn foo(_: impl Trait: &TypeName) {}
| ~~~~~~~~~~~~~~~~
help: if this is a type, explicitly ignore the parameter name
|
2 | fn foo(_: impl _: &Trait) {}
| ++
error: expected one of `!`, `(`, `)`, `,`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^ expected one of 9 possible tokens
| |
| help: missing `,`
error: expected one of `!`, `(`, `,`, `=`, `>`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| ^ expected one of 10 possible tokens
```
After:
```text
error: expected a trait, found type
--> <anon>:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^^^^^
| |
| help: consider removing the indirection
error: expected a trait, found type
--> <anon>:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| -^^^^^
| |
| help: consider removing the indirection
```
|
|
|
|
Parse `-> Ty | OtherTy`.
Parse type ascription in top level patterns.
|
|
|
|
Remove various double spaces in compiler source comments.
Was asked to do it by `@Nilstrieb`
|
|
|
|
Allocate one less vec while parsing arrays
Probably does not matter, but imo a little bit nicer.
|
|
|
|
|
|
|
|
|
|
|
|
Const closures
cc https://github.com/rust-lang/rust/issues/106003
|
|
|
|
|
|
fmease:recover-where-clause-before-tuple-struct-body, r=estebank
Recover from where clauses placed before tuple struct bodies
Open to any suggestions regarding the phrasing of the diagnostic.
Fixes #100790.
`@rustbot` label A-diagnostics
r? diagnostics
|
|
|
|
Fix #82051.
|
|
Fix #79161.
|
|
|
|
fix comment for `TokenCursor::desugar`
the hashes of the text were forgotten.
|
|
Rollup of 9 pull requests
Successful merges:
- #104531 (Provide a better error and a suggestion for `Fn` traits with lifetime params)
- #105899 (`./x doc library --open` opens `std`)
- #106190 (Account for multiple multiline spans with empty padding)
- #106202 (Trim more paths in obligation types)
- #106234 (rustdoc: simplify settings, help, and copy button CSS by not reusing)
- #106236 (docs/test: add docs and a UI test for `E0514` and `E0519`)
- #106259 (Update Clippy)
- #106260 (Fix index out of bounds issues in rustdoc)
- #106263 (Formatter should not try to format non-Rust files)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
the hashes of the text were forgotten.
|
|
Detect diff markers in the parser
Partly address #32059.
|