| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
available
|
|
|
|
|
|
|
|
When encountering an unsatisfied trait bound, if there are no other
suggestions, mention all the types that *do* implement that trait:
```
error[E0277]: the trait bound `f32: Foo` is not satisfied
--> $DIR/impl_wf.rs:22:6
|
LL | impl Baz<f32> for f32 { }
| ^^^^^^^^ the trait `Foo` is not implemented for `f32`
|
= help: the following other types implement trait `Foo`:
Option<T>
i32
str
note: required by a bound in `Baz`
--> $DIR/impl_wf.rs:18:31
|
LL | trait Baz<U: ?Sized> where U: Foo { }
| ^^^ required by this bound in `Baz`
```
Mention implementers of traits in `ImplObligation`s.
Do not mention other `impl`s for closures, ranges and `?`.
|
|
|
|
|
|
|
|
|
|
This should make it easier to read.
|
|
Now, multipart suggestions are used instead of `span_to_snippet`, which
improves code quality, makes the suggestion work even without access to
source code, and, most importantly, improves the rendering of the
suggestion.
|
|
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
Address part of #89418.
|
|
|
|
|
|
Warn when an escaped newline skips multiple lines
Resolves #87319
|
|
|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
* Use more accurate span for `async move` suggestion
* Use more accurate span for deref suggestion
* Use `multipart_suggestion` more often
|
|
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make `str` indexing generic on `SliceIndex`.
Fixes #55603
|
|
Implement new literal type `Err`
Fixes #57384
I removed `return Ok`, otherwise, two errors occur. Any solutions?
r? @estebank
|
|
|
|
Better error note on unimplemented Index trait for string
fixes #56740
I've tried to compile suggestion from comments in the issue #56740, but unsure of it. So I'm open to advice :)
Current output will be like this:
```rust
error[E0277]: the type `str` cannot be indexed by `{integer}`
--> $DIR/str-idx.rs:3:17
|
LL | let c: u8 = s[4]; //~ ERROR the type `str` cannot be indexed by `{integer}`
| ^^^^ `str` cannot be indexed by `{integer}`
|
= help: the trait `std::ops::Index<{integer}>` is not implemented for `str`
= note: you can use `.chars().nth()` or `.bytes().nth()`
see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
`x.py test src/test/ui` succeeded and I've also tested output manually by compiling the following code:
```rust
fn _f() {
let s = std::string::String::from("hello");
let _c = s[0];
let s = std::string::String::from("hello");
let mut _c = s[0];
let s = "hello";
let _c = s[0];
let s = "hello";
let mut _c = &s[0];
}
```
Not sure if some docs should be changed too. I will also fix error message in the [Book :: Indexing into Strings](https://github.com/rust-lang/book/blob/db53e2e3cdf77beac853df6f29db4b3b86ea598c/src/ch08-02-strings.md#indexing-into-strings) if that PR will get approved :)
|
