| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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
|
|
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`
|
|
|
|
Escape string literals when fixing overlong char literal
Fixes #103323
````@rustbot```` label +A-diagnostics +A-suggestion-diagnostics
|
|
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.
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #101360 (Point out incompatible closure bounds)
- #101789 (`let`'s not needed in struct field definitions)
- #102846 (update to syn-1.0.102)
- #102871 (rustdoc: clean up overly complex `.trait-impl` CSS selectors)
- #102876 (suggest candidates for unresolved import)
- #102888 (Improve rustdoc-gui search-color test)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`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'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.
|
|
It has a single call site.
|
|
Because they're very similar, and this will allow some follow-up
changes.
|
|
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.
|
|
|
|
|
|
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.
|
|
More lexer improvements
A follow-up to #99884.
r? `@matklad`
|
|
|
|
Structured suggestion for missing `mut`/`const` in raw pointer
Fixes #102261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
