Improve unresolved use error message
"use of undeclared type or module `foo`" doesn't mention that it could be a crate.
This error can happen when users forget to add a dependency to `Cargo.toml`, so I think it's important to mention that it could be a missing crate.
I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter, and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.
If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.
This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.
This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.
On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.
This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
additional context for the recursive call.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
Add explanation for `&mut self` method call when expecting `-> Self`
When a user tries to use a method as if it returned a new value of the
same type as its receiver, we will emit a type error. Try to detect this
and provide extra explanation that the method modifies the receiver
in-place.
This has confused people in the wild, like in
https://users.rust-lang.org/t/newbie-why-the-commented-line-stops-the-snippet-from-compiling/47322
Do not emit E0228 when it is implied by E0106
Emit E0288 (lifetime bound for trait object cannot be deduced) only on bare trait objects. When the trait object is in the form of `&dyn Trait`, E0106 (missing lifetime specifier) will have been emitted, making the former redundant.
Emit E0288 (lifetime bound for trait object cannot be deduced) only on
bare trait objects. When the trait object is in the form of
`&dyn Trait`, E0106 (missing lifetime specifier) will have been emitted,
making the former redundant.
Fix suggestion to use lifetime in type and in assoc const
_Do not merge until #75363 has landed, as it has the test case for this._
* Account for associated types
* Associated `const`s can't have generics (fix#74264)
* Do not suggest duplicate lifetimes and suggest `for<'a>` more (fix#72404)
* Deduplicate type ascription LHS errors
* Remove duplicated `:` -> `::` suggestion from parse error
* Tweak wording to be more accurate
* Modify `current_type_ascription` to reduce span wrangling
* remove now unnecessary match arm
* Add run-rustfix to appropriate tests
When encountering a unit or tuple pattern for a struct-like item, suggest
using the correct pattern.
Use `insert_field_names_local` when evaluating variants and store field
names even when the list is empty in order to produce accurate
structured suggestions.
Tweak `::` -> `:` typo heuristic and reduce verbosity
Do not trigger on correct type ascription expressions with trailing
operators and _do_ trigger on likely path typos where a turbofish is
used.
On likely path typos, remove note explaining type ascription.
Clean up indentation.
r? @petrochenkov
Do not trigger on correct type ascription expressions with trailing
operators and _do_ trigger on likely path typos where a turbofish is
used.
On likely path typos, remove note explaining type ascription.
Audit hidden/short code suggestions
Should fix#73641.
Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes.
r? @estebank
This commit modifies resolve to disallow `break`/`continue` to labels
through closures or async blocks. This doesn't make sense and should
have been prohibited anyway.
Signed-off-by: David Wood <david@davidtw.co>
Adds a clearer message for when the async keyword is missing from a f…
…unction
This is a somewhat simple fix for #66731.
Under the current version of Rust, if a user has a rust file that looks like this:
```rust
fn boo (){}
async fn foo() {
boo().await;
}
fn main() {
}
```
And they attempt to run it, they will receive an error message that looks like this:
```bash
error: incorrect use of `await` --> test.rs:4:14 | 4 | boo.await(); | ^^ help: `await` is not a method call, remove the parentheses error[E0277]: the trait bound `fn() {boo}: std::future::Future` is not satisfied --> test.rs:4:5 | 4 | boo.await(); | ^^^^^^^^^ the trait `std::future::Future` is not implemented for `fn() {boo}` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`.
```
This is not very clear.
With the changes made in this PR, when a user compiles and runs that same rust code, they will receive an error message that looks like this:
```bash
error[E0277]: `()` is not a future.
--> test.rs:4:5
|
4 | boo().await;
| ^^^^^^^^^^^ `()` is not a future
|
= help: the trait `std::future::Future` is not implemented for `()`
= note: required by `std::future::Future::poll`
```
In the future, I think we should make this error message even clearer, perhaps through a solution like the one described in [this comment](https://github.com/rust-lang/rust/issues/66731#issuecomment-644394287). However, as that potentially involves a major change proposal, I would rather get this change in now and make the error message a little clearer while an MCP is drafted and discussed.
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
Verify that the binop trait *is* implemented for the types *if* all the
involved type parameters are replaced with fresh inferred types. When
this is the case, it means that the type parameter was indeed missing a
trait bound. If this is not the case, provide a generic `note` refering
to the type that doesn't implement the expected trait.
Account for multiple impl/dyn Trait in return type when suggesting `'_`
Make `impl` and `dyn` Trait lifetime suggestions a bit more resilient.
Follow up to #72804.
r? @nikomatsakis
Improve compiler error message for wrong generic parameter order
- Added optional "help" parameter that shows a help message on the compiler error if required.
- Added a simple ordered parameter as a sample help.
@varkor will make more changes as required. Let me know if I'm heading in the right direction.
Fixes#68437
r? @varkor
