| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Co-authored-by: varkor <github@varkor.com>
|
|
Suggest calling associated `fn` inside `trait`s
When calling a function that doesn't exist inside of a trait's
associated `fn`, and another associated `fn` in that trait has that
name, suggest calling it with the appropriate fully-qualified path.
Expand the label to be more descriptive.
Prompted by the following user experience:
https://users.rust-lang.org/t/cannot-find-function/50663
|
|
|
|
When calling a function that doesn't exist inside of a trait's
associated `fn`, and another associated `fn` in that trait has that
name, suggest calling it with the appropriate fully-qualified path.
Expand the label to be more descriptive.
Prompted by the following user experience:
https://users.rust-lang.org/t/cannot-find-function/50663
|
|
Rollup of 10 pull requests
Successful merges:
- #74477 (`#[deny(unsafe_op_in_unsafe_fn)]` in sys/wasm)
- #77836 (transmute_copy: explain that alignment is handled correctly)
- #78126 (Properly define va_arg and va_list for aarch64-apple-darwin)
- #78137 (Initialize tracing subscriber in compiletest tool)
- #78161 (Add issue template link to IRLO)
- #78214 (Tweak match arm semicolon removal suggestion to account for futures)
- #78247 (Fix #78192)
- #78252 (Add codegen test for #45964)
- #78268 (Do not try to report on closures to avoid ICE)
- #78295 (Add some regression tests)
Failed merges:
r? `@ghost`
|
|
Fix #77218. Fix #77238.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix #77598.
|
|
Use correct article in help message for conversion or cast
Before it always used `an`; now it uses the correct article for the type.
|
|
Refactor io/buffered.rs into submodules
This pull request splits `BufWriter`, `BufReader`, `LineWriter`, and `LineWriterShim` (along with their associated tests) into separate submodules. It contains no functional changes. This change is being made in anticipation of adding another type of buffered writer which can be switched between line- and block-buffering mode.
Part of a series of pull requests resolving #60673.
|
|
|
|
This unfortunately requires some winnowing hacks to avoid
now ambiguous candidates.
|
|
|
|
|
|
Also added missing backtick in "you can cast" message.
|
|
Co-authored-by: Dhruv Jauhar <dhruvjhr@gmail.com>
Co-authored-by: Logan Mosier <logmosier@gmail.com>
|
|
|
|
|
|
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.
|
|
|
|
Detect potential cases where `if let` was meant but `let` was left out.
Fix #44990.
|
|
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
|
|
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)
|
|
Detect JS-style `===` and `!==` and recover
Fix #75312.
|
|
|
|
Fix #72404.
|
|
Fix #74264.
|
|
Modify logic to make it easier to follow and recover labels that would
otherwise be lost.
|
|
Fix #75312.
|
|
* 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
|
|
|
|
Detect turbofish missing surrounding angle brackets
Fix #74065.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
