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`
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
Flatten diagnostic slug modules
This makes it easier to grep for the slugs in the code.
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error for more discussion about it.
This was mostly done with a few regexes and a bunch of manual work. This also exposes a pretty annoying inconsistency for the extra labels. Some of the extra labels are defined as additional properties in the fluent message (which makes them not prefixed with the crate name) and some of them are new fluent messages themselves (which makes them prefixed with the crate name). I don't know whether we want to clean this up at some point but it's useful to know.
r? `@davidtwco`
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.
It's now only used in one function. Also, the "should we glue the
tokens?" check is only necessary when pushing a `TokenTree::Token`, not
when pushing a `TokenTree::Delimited`.
As part of this, we now do the "should we glue the tokens?" check
immediately, which avoids having look back at the previous token. It
also puts all the logic dealing with token gluing in a single place.
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`
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.
Migrate more of rustc_parse to SessionDiagnostic
Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
