| Age | Commit message (Collapse) | Author | Lines |
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
|
|
E0599 suggestions and elision of generic argument if no canditate is found
fixes #81576
changes: In error E0599 (method not found) generic argument are eluded if the method was not found anywhere. If the method was found in another inherent implementation suggest that it was found elsewhere.
Example
```rust
struct Wrapper<T>(T);
struct Wrapper2<T> {
x: T,
}
impl Wrapper2<i8> {
fn method(&self) {}
}
fn main() {
let wrapper = Wrapper(i32);
wrapper.method();
let wrapper2 = Wrapper2{x: i32};
wrapper2.method();
}
```
```
Error[E0599]: no method named `method` found for struct `Wrapper<_>` in the current scope
....
error[E0599]: no method named `method` found for struct `Wrapper2<i32>` in the current scope
...
= note: The method was found for Wrapper2<i8>.
```
I am not very happy with the ```no method named `test` found for struct `Vec<_, _>` in the current scope```. I think it might be better to show only one generic argument `Vec<_>` if there is a default one. But I haven't yet found a way to do that,
|
|
|
|
|
|
|
|
|
|
anywhere and sugetion of type with method when found.
|
|
This is step 2 towards fixing #77548.
In the codegen and codegen-units test suites, the `//` comment markers
were kept in order not to affect any source locations. This is because
these tests cannot be automatically `--bless`ed.
|
|
|
|
This reverts commit 22ae20733515d710c1134600bc1e29cdd76f6b9b.
|
|
collisions I could imagine.
The different impls are all guarded by cfg-flags, and the revisions could be
used to cover the full power-set of combinations.
(I only included 20 of the possible 32 cases here; the null-set is not
interesting, and the remaining 11 all yielded ambiguous method resolution errors
which did not mix well with this testing strategy; I'm not trying to check UI
for the resolution diagnostics; I'm trying to create checkpoint of current
resolution semantics when compilation succeeds.)
|
|
Fixes #76267
When there is a single applicable method candidate, but its trait bounds
are not satisfied, we avoid saying that the method is "not found".
Insted, we update the error message to directly mention which bounds are
not satisfied, rather than mentioning them in a note.
|
|
|
|
|
|
|
|
|
|
Use correct article in help message for conversion or cast
Before it always used `an`; now it uses the correct article for the type.
|
|
|
|
|
|
Also added missing backtick in "you can cast" message.
|
|
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.
|
|
|
|
|
|
Rename fn_has_self_argument to fn_has_self_parameter
Rename AssocItemKind::Method to AssocItemKind::Fn
Refine has_no_input_arg
Refine has_no_input_arg
Revert has_no_input_arg
Refine suggestion_descr
Move as_def_kind into AssocKind
Signed-off-by: Rustin-Liu <rustin.liu@gmail.com>
Fix tidy check issue
Signed-off-by: Rustin-Liu <rustin.liu@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove use of `unwrap()` from save-analysis
Fix #69409, fix #69416
|
|
|
|
|
|
When the obligation that couldn't be fulfilled is specific to a nested
obligation, maintain both the nested and parent obligations around for
more accurate and detailed error reporting.
|
|
Surface associated type projection bounds that could not be fulfilled in
E0599 errors. Always present the list of unfulfilled trait bounds,
regardless of whether we're pointing at the ADT or trait that didn't
satisfy it.
|
|
|
|
|
|
Point at the intermediary unfullfilled trait bounds.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Use structured suggestion for disambiguating method calls
Fix #65635.
|
|
|
|
Fix #65635.
|