| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=estebank
Fix unused lint and parser caring about spaces to won't produce invalid code
Fixes #103435
|
|
Recover wrong-cased keywords that start items
(_this pr was inspired by [this tweet](https://twitter.com/Azumanga/status/1552982326409367561)_)
r? `@estebank`
We've talked a bit about this recovery, but I just wanted to make sure that this is the right approach :)
For now I've only added the case insensitive recovery to `use`s, since most other items like `impl` blocks, modules, functions can start with multiple keywords which complicates the matter.
|
|
Rollup of 9 pull requests
Successful merges:
- #102763 (Some diagnostic-related nits)
- #103443 (Parser: Recover from using colon as path separator in imports)
- #103675 (remove redundent "<>" for ty::Slice with reference type)
- #104046 (bootstrap: add support for running Miri on a file)
- #104115 (Migrate crate-search element to CSS variables)
- #104190 (Ignore "Change InferCtxtBuilder from enter to build" in git blame)
- #104201 (Add check in GUI test for file loading failure)
- #104211 (:arrow_up: rust-analyzer)
- #104231 (Update mailmap)
Failed merges:
- #104169 (Migrate `:target` rules to use CSS variables)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=compiler-errors
Parser: Recover from using colon as path separator in imports
I don't know if this is the right approach, any feedback is welcome.
r? ```@compiler-errors```
Fixes #103269
|
|
r=jackh276,davidtwco
Recover from common if let syntax mistakes/typos
Fixes #103587
|
|
|
|
|
|
Co-authored-by: clubby789 <jamie@hill-daniel.co.uk>
|
|
|
|
|
|
compiler-errors:oh-no-bad-block-should-not-have-label, r=lcnr
Don't silently eat label before block in block-like expr
Fixes #103983
cc #92823 (where the regression was introduced)
|
|
|
|
|
|
|
|
|
|
Mainly in `expr.rs`
|
|
Add flag to forbid recovery in the parser
To start the effort of fixing #103534, this adds a new flag to the parser, which forbids the parser from doing recovery, which it shouldn't do in macros.
This doesn't add any new checks for recoveries yet and is just here to bikeshed the names for the functions here before doing more.
r? `@compiler-errors`
|
|
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
|
|
|
|
Remove extra type error after missing semicolon error
Fixes #103425
|
|
|
|
Fix assertion failed for break_last_token and trailing token
Fixes #103143
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #101293 (Recover when unclosed char literal is parsed as a lifetime in some positions)
- #101908 (Suggest let for assignment, and some code refactor)
- #103192 (rustdoc: Eliminate uses of `EarlyDocLinkResolver::all_traits`)
- #103226 (Check `needs_infer` before `needs_drop` during HIR generator analysis)
- #103249 (resolve: Revert "Set effective visibilities for imports more precisely")
- #103305 (Move some tests to more reasonable places)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Recover when unclosed char literal is parsed as a lifetime in some positions
Fixes #101278
|
|
|
|
macro
|
|
|
|
Filtering spans when emitting json
According to the issue #102902, we shouldn't emit spans which have an empty span and no suggested replacement.
|
|
|
|
|
|
|
|
|
|
Fix `let` keyword removal suggestion in structs
(1.) Fixes a bug where, given this code:
```rust
struct Foo {
let x: i32,
}
```
We were parsing the field name as `let` instead of `x`, which causes issues later on in the type-checking phase.
(2.) Also, suggestions for `let: i32` as a field regressed, displaying this extra `help:` which is removed by this PR
```
help: remove the let, the `let` keyword is not allowed in struct field definitions
|
2 - let: i32,
2 + : i32,
```
(3.) Makes the suggestion text a bit more succinct, since we don't need to re-explain that `let` is not allowed in this position (since it's in a note that follows). This causes the suggestion to render inline as well.
cc `@gimbles,` this addresses a few nits I mentioned in your PR.
|
|
|
|
|
|
`let`'s not needed in struct field definitions
Fixes #101683
|
|
Co-authored-by: jyn514 <jyn514@gmail.com>
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
|
|
Recover from impl Trait in type param bound
Fixes #102182
r? ``@estebank``
|
|
|
|
|
|
It took me some time to work out what this code was doing.
|
|
Remove `expr_parentheses_needed` from `ParseSess`
Not sure why this method needed to exist on `ParseSess`, but we can achieve the same behavior by just inlining it everywhere.
|
|
|
|
|
|
|
|
Group together more size assertions.
Also add a few more assertions for some relevant token-related types.
And fix an erroneous comment in `rustc_errors`.
r? `@lqd`
|
|
Also add a few more assertions for some relevant token-related types.
And fix an erroneous comment in `rustc_errors`.
|
|
r=fee1-dead
Improve errors for incomplete functions in struct definitions
Given the following code:
```rust
fn main() {}
struct Foo {
fn
}
```
[playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=29139f870511f6918324be5ddc26c345)
The current output is:
```
Compiling playground v0.0.1 (/playground)
error: functions are not allowed in struct definitions
--> src/main.rs:4:5
|
4 | fn
| ^^
|
= help: unlike in C++, Java, and C#, functions are declared in `impl` blocks
= help: see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information
error: could not compile `playground` due to previous error
```
In this case, rustc should suggest escaping `fn` to use it as an identifier.
|
