This still doesn't handle the case entirely correctly, requiring a more
targeted approach with a better suggestion, but at least now the
suggested syntax makes *some* sense.
Initial implementation of `#![feature(bindings_after_at)]`
Following up on #16053, under the gate `#![feature(bindings_after_at)]`, `x @ Some(y)` is allowed subject to restrictions necessary for soundness.
The implementation and test suite should be fairly complete now.
One aspect that is not covered is the interaction with nested `#![feature(or_patterns)]`.
This is not possible to test at the moment in a good way because that feature has not progressed sufficiently and has fatal errors in MIR building. We should make sure to add such tests before we stabilize both features (but shipping one of them is fine).
r? @pnkfelix
cc @nikomatsakis @matthewjasper @pcwalton
cc https://github.com/rust-lang/rust/issues/65490
Indicate origin of where type parameter for uninferred types
Based on #65951 (which is not merge yet), fixes#67277.
This PR improves a little the diagnostic for code like:
```
async fn foo() {
bar().await;
}
async fn bar<T>() -> () {}
```
by showing:
```
error[E0698]: type inside `async fn` body must be known in this context
--> unresolved_type_param.rs:9:5
|
9 | bar().await;
| ^^^ cannot infer type for type parameter `T` declared on the function `bar`
|
...
```
(The
```
declared on the function `bar`
```
part is new)
A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`.
r? @estebank
Improve diagnostics and code for exhaustiveness of empty matches
There was a completely separate check and diagnostics for the case of an empty match. This led to slightly different error messages and duplicated code.
This improves code reuse and generally clarifies what happens for empty matches. This also clarifies the action of the `exhaustive_patterns` feature, and ensures that this feature doesn't change diagnostics in places it doesn't need to.
Remove cannot mutate statics in initializer of another static error
r? @oli-obk
This is just a refactoring. As the removed code itself said, it only a heuristic catching a few cases early instead of leaving it all to const eval. It's easy to work around the static check and then run into the miri-engine check.
Improve the "try using a variant of the expected type" hint.
Fix https://github.com/rust-lang/rust/issues/65494.
- Change type-printing output.
- Use `span_to_snippet` when possible.
- Change the message to `try using a variant of the expected enum`
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.
