| Age | Commit message (Collapse) | Author | Lines |
|---|
|
when they don't
|
|
bindings_after_at: harden tests
|
|
Address inconsistency in using "is" with "declared here"
"is" was generally used for NLL diagnostics, but not other diagnostics. Using "is" makes the diagnostics sound more natural and readable, so it seems sensible to commit to them throughout.
r? @Centril
|
|
|
|
|
|
|
|
adding one
|
|
This doesn't mention that using an existing lifetime is possible, but
that would hopefully be clear as always being an option. The intention
of this is to teach newcomers what the lifetime syntax is.
|
|
|
|
Account for common `impl Trait`/`dyn Trait` return type errors
- When all return paths have the same type, suggest `impl Trait`.
- When all return paths implement the expected `trait`, suggest `Box<dyn Trait>` and mention using an `enum`.
- When multiple different types are returned and `impl Trait` is expected, extend the explanation.
- When return type is `impl Trait` and the return paths do not implement `Trait`, point at the returned values.
- Split `src/librustc/traits/error_reporting.rs` into multiple files to keep size under control.
Fix #68110, cc #66523.
|
|
|
|
|
|
|
|
|
|
When a type error involves a `dyn Trait` as the return type, do not emit
the type error, as the "return type is not `Sized`" error will provide
enough information to the user.
|
|
Suggest `impl Trait` when possible, and `Box<dyn Trait>` otherwise.
|
|
Fix some issue numbers of unstable features
Looking into the unstable book, some issue numbers are outdated.
|
|
|
|
|
|
Also fix a bug with the span passed in `mk_range`.
|
|
Unify output of "variant not found" errors
Fix #49566.
|
|
|
|
|
|
|
|
|
|
Cleanup pattern type checking, fix diagnostics bugs (+ improvements)
r? @estebank
|
|
Suggest type param when encountering `_` in item signatures
Fix #27435.
|
|
The existing wording was inappropriate for e.g.
`if let Ok(_) = expr { .. }`. The diagnostic would
leak the fact that we desugar to a `match`.
|
|
|
|
When encountering `_` type placeholder in fn arguments and return type,
suggest using generic type parameters.
Expand what counts as an inferable return type to slice, array and
tuples of `_`.
|
|
|
|
|
|
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
|
|
|
|
|
|
Under the gate, `x @ Some(y)` is allowed.
This is subject to various restrictions for soundness.
|
|
|
|
|
|
|
|
r=estebank
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
|
|
Use structured suggestion for disambiguating method calls
Fix #65635.
|
|
|
|
Point at method call when type annotations are needed
- Point at method call instead of whole expression when type annotations are needed.
- Suggest use of turbofish on function and methods.
Fix #49391, fix #46333, fix #48089. CC #58517, #63502, #63082.
Fixes https://github.com/rust-lang/rust/issues/40015
r? @nikomatsakis
|
|
r=varkor,Centril,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.
|
|
|
|
Fix #65635.
|
|
|
|
|
