| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The existing wording was inappropriate for e.g.
`if let Ok(_) = expr { .. }`. The diagnostic would
leak the fact that we desugar to a `match`.
|
|
|
|
Specific labels when referring to "expected" and "found" types
|
|
Add outlives suggestions for some lifetime errors
This PR implements suggestion diagnostics for some lifetime mismatch errors. When the borrow checker finds that some lifetime 'a doesn't outlive some other lifetime 'b that it should outlive, then in addition to the current lifetime error, we also emit a suggestion for how to fix the problem by adding a bound:
- If a and b are normal named regions, suggest to add the bound `'a: 'b`
- If b is static, suggest to replace a with static
- If b also needs to outlive a, they must be the same, so suggest unifying them
We start with a simpler implementation that avoids diagnostic regression or implementation complexity:
- We only makes suggestions for lifetimes the user can already name (eg not closure regions or elided regions)
- For now, we only emit a help note, not an actually suggestion because it is significantly easier.
Finally, there is one hack: it seems that implicit regions in async fn are given the name '_ incorrectly. To avoid suggesting '_: 'x, we simply filter out such lifetimes by name.
For more info, see this internals thread:
https://internals.rust-lang.org/t/mechanical-suggestions-for-some-borrow-checker-errors/9049/3
TL;DR Make suggestions to add a `where 'a: 'b` constraint for some lifetime errors. Details are in the paper linked from the internals thread above.
r? @estebank
TODO
- [x] Clean up code
- [x] Only make idiomatic suggestions
- [x] don't suggest naming `&'a self`
- [x] rather than `'a: 'static`, suggest replacing `'a` with `'static`
- [x] rather than `'a: 'b, 'b: 'a`, suggest replacing `'a` with `'b` or vice versa
- [x] Performance (maybe need a perf run when this is closer to the finish line?)
- perf run was clean...
- EDIT: perf run seems to only check non-error performance... How do we check that error performance didn't regress?
- [x] Needs ui tests
- [x] Integrate the `help` message into the main lifetime `error`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Point at local similarly named element and tweak references to variants
Partially address #65386.
|
|
I took most tests that were testing only for match exhaustiveness,
pattern refutability or match arm reachability, and put them in
the same test folder.
|
|
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
|
|
|
|
|
|
|
|
|
|
|
|
Print lifetimes with backticks
Fixes #65287
r? @varkor
|
|
|
|
|
|
|
|
Fixes #64590
When we emit an 'unreachable' lint, we now add a note pointing at the
expression that actually causes the code to be unreachable (e.g.
`return`, `break`, `panic`).
This is especially useful when macros are involved, since a diverging
expression might be hidden inside of a macro invocation.
|
|
check_match: refactor + improve non-exhaustive diagnostics for default binding modes
Refactor `check_match` a bit with more code-reuse and improve the diagnostics for a non-exhaustive pattern match by peeling off any references from the scrutinee type so that the "defined here" label is added in more cases. For example:
```rust
error[E0004]: non-exhaustive patterns: `&mut &B` not covered
--> foo.rs:4:11
|
1 | enum E { A, B }
| ---------------
| | |
| | not covered
| `E` defined here
...
4 | match x {
| ^ pattern `&mut &B` not covered
|
= help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
```
Moreover, wrt. "defined here", we give irrefutable pattern matching (i.e. in `let`, `for`, and `fn` parameters) a more consistent treatment in line with `match`.
r? @estebank
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While many programmers may intuitively appreciate the significance of
"magic numbers" like −2147483648, Rust is about empowering everyone to
build reliable and efficient software! It's a bit more legible to
print the constant names (even noisy fully-qualified-paths thereof).
The bit-manipulation methods mirror those in
`librustc_mir::hair::pattern::_match::all_constructors`; thanks to the
immortal Varkor for guidance.
Resolves #56393.
|
|
|
|
Add test for issue-50900
Closes #50900
|
|
|
|
|
|
|
|
https://github.com/rust-lang/rust/issues/60532
|
