Actually Rust diagnostic as pretty good, especially comparing to C/C++. However many errors are quite puzzling for non experienced Rust coders as myself, for example:
error[E0277]: the trait bound `Vec<&str>: Extend<String>` is not satisfied
--> /media/exhdd/Dev/modu/question/question.rs:13:10
|
13 | init.extend(read_dir(dir)?.filter_map(|cur| {
| ^^^^^^ the trait `Extend<String>` is not implemented for `Vec<&str>`
|
help: the following other types implement trait `Extend<A>`
--> /rustc/ac7f9ec7da74d37fd28667c86bf117a39ba5b02a/library/alloc/src/vec/mod.rs:3949:0
|
= note: `Vec<T, A>` implements `Extend<T>`
::: /rustc/ac7f9ec7da74d37fd28667c86bf117a39ba5b02a/library/alloc/src/vec/mod.rs:4184:0
|
= note: `Vec<T, A>` implements `Extend<&T>`
error: aborting due to 1 previous error
extend method is specifically designed for extending a vector from an Iterator, so why Rust tells - is not satisfied ? I would prefer something more human friendly and even AI driven like,
You are trying to extend a vector containing a &str by an Iterator producing String, make it consistent, for example adding to_string in the context:
I prefer diagnostics to be deterministic. This specific error could get a better diagnostics if the two types are related via ToOwned or similar. Just file an issue, diagnostics issues get fixed very quickly in my experience.
I'm not aware of any serious plans for a Rust 2.0 or for a revolutionary shift in error diagnostics.
But the diagnostics are always being improved.
Is this part clear to you? (It's very clear to me.)
error[E0277]: the trait bound `Vec<&str>: Extend<String>` is not satisfied
--> /media/exhdd/Dev/modu/question/question.rs:13:10
|
13 | init.extend(read_dir(dir)?.filter_map(|cur| {
| ^^^^^^ the trait `Extend<String>` is not implemented for `Vec<&str>`
But the relevance of what follows isn't necessarily clear without consulting the docs, I would say. Something nicer but still technical would be
`Vec::<String>::extend` takes any `T: IntoIterator<Item = String>` as a
parameter.
...
something suggesting `some_str.to_owned()` at the appropriate spot
(bonus points for avoiding `Vec` and passing along an iterator if possible)
(Which requires that the error reporting understand generics, finds the implementations, and rules out the ones that don't apply.)
I want something pointing me at the relevant implementations or failed trait bounds, etc. That is, technical explanations. The long form errors could be expanded some, but I don't want something emulating a human conversation in my inline errors.
I'm not sure exactly what you had in mind with AI, but hooking the compiler up to some dynamic third-party AI should be an explicit client-side action and configuration (i.e. not a part of default diagnostics). Better suited to an IDE than the compiler itself IMO.
Sorry, I meant version - 1.101. I also have a web server I planned to make the version 2.0, however after some thinking, I discarded the idea and now it has version - 1.126. So our thinking is aligned.
I use copilot, but it was useless in the case.
It's unclear, because I use the function a quite bit and always it compiled without a problem. And suddenly it stopped. We use to see the compiler suggestion which instructs how the problem can be fixed, and usually even not a single. You approach is certainly right, I need to read the error message and clear understand it, and then apply a correct fix. So, my intention was also very clear - we have AI around, so what's its value if we still should do everything ourselves? We pay quite money for AI, so let it to work for us.
Some time ago I used PL/I compiler from IBM. Since I didn't have a direct access to the computer, correcting any mistake took a day or two. So the authors of the compiler implemented auto-fix errors, so the compiler could fix correctly many errors and then execute my program. I didn't ask Rust compiler for such help, although I really liked it.
Changing this error to something like "Values with the type Vec<&str> cannot be extended with values of type String" should be a few lines of code to add to the standard library. Just need to add a rustc_on_unimplemented attribute on the Extend trait.
Figuring anything else further than that is very difficult. Rust would need to read your mind to figure out whether the Vec<&str> has the wrong type or the String has the wrong type. Then, once it figures out that you needed the Vec<&str> to be a Vec<String>, it would need to somehow explain to you why it thought that the variable had type Vec<&str>. Doing so requires translating the type inference algorithm (which is in the style of equation-solving) into a step-by-step reasoning chain. This chain has many steps, including multiple steps that go through the standard library. Unless you want a screenful of nonsense, Rust would need to somehow guess which step is relevant to you. And only then, Rust can tell you where the issue is.
Perhaps AI could help in "simple" cases like this. However, distributing that with the compiler is probably logistically difficult. Also, current AI is too prone to hallucinating the wrong answers, and probably won't be very helpful for more complicated errors anyway.
If you want to use AI to explain errors, an external tool that reads the compiler output seems much more appropriate. I wouldn't be surprised if such a tool already exists.
Since error messages are so customizable, I think that first step could be providing error explanation links as it's done for Clippy. I use the feature a lot, because many Clippy recommendation look questionable, however after reading the linked details, I can decide if I need to obey the suggestion, or can comment out it as ignore.
It would be wonderful if you could formalize rules for generation a link to the error details?
error[E0277]: the trait bound `Vec<&str>: Extend<String>` is not satisfied
--> /media/exhdd/Dev/modu/question/question.rs:13:10
|
13 | init.extend(read_dir(dir)?.filter_map(|cur| {
| ^^^^^^ the trait `Extend<String>` is not implemented for `Vec<&str>`
|
help: the following other types implement trait `Extend<A>`
--> /rustc/ac7f9ec7da74d37fd28667c86bf117a39ba5b02a/library/alloc/src/vec/mod.rs:3949:0
|
= note: `Vec<T, A>` implements `Extend<T>`
::: /rustc/ac7f9ec7da74d37fd28667c86bf117a39ba5b02a/library/alloc/src/vec/mod.rs:4184:0
|
= note: `Vec<T, A>` implements `Extend<&T>`
error: aborting due to 1 previous error
So I can build a regex to convert the error pattern, like error[E0277] to a URL linked to your page.
BTW maybe you also know how I can construct URLs for references to /rustc/ac7f9ec7da74d37fd28667c86bf117a39ba5b02a/library/alloc/src/vec/mod.rs:4184:0.
Then that one machine has had rustup default nightly run (or you ran it on a repo with a nightly toolchain set) - that's probably not what you want
Nightly features aren't guaranteed to stabilized at any particular version, or at all. You can track the issue here, but it doesn't look like there's a lot of movement since it's original acceptance. (Following a few of the links it looks like it's been rolled up into a larger effort to improve diagnostic formatting that's still active)
It's correct, my policy is to run at least one release behind of the current stable. However, I do not mind if my code (and tools) is a bit future proof.
That policy you follow kind of gets in the way of getting the best errors you could. Every six weeks we get diagnostic improvements on stable, more often than that on nightly. I used to advice people to use nightly for development and stable for production back when we had lots of improvements weekly. It is less necessary now, but would still advice to use the newest toolchain you can for development if you care about diagnostic quality.
Is trying to say "Vec<T> can be extended by something that has T or &T". But you have Vec<&str> and String. I would love us to have a way of surfacing the next step of explaining that, but doing it in a generic way, for trait bounds for third party crates, would be very difficult. Special casing this only for the std could be done, but we try to implement code that understand the code when possible, instead of pattern matching on known cases. But we are not above doing that.
As a side note, I guess it would make sense to suggest installing rust-src when we can't find the sources for std...
Finally, improving diagnostics don't require a Rust 2.0: the compiler output has no stability guarantees and as long as you can improve it without needing language changes, it is fair game. We even have the #[diagnostic] namespace now explicitly for allowing crates to influence the diagnostics.
On some luck, the machine where I do most of my experimenting activities, has the nightly tool chain.
Regarding the error message, I would add an advice that the original vector should contain String initially to eliminate the error. Indeed, I inserted there 'strings' first, but forgot to convert them to_string. It's a frequent mistake for me and I believe for others too. String and &str types are very similar, and when you use a string literal, you do not use any '&', although Rust considers it such. Rust has several messages as - consider using... for other errors, probably a similar suggestion should be added in this case too.
Since error messages are so customizable, I think that first step could be providing error explanation links as it's done for Clippy.
Sorry, but I don't understand what you're imagining here. Do you want an error explanation that would be linked to every time that an error occurs because some type doesn't implement Extend?
This is not feasible. The compiler only knows that you have a Vec<&str> and is trying to add a String to it. It doesn't know if the &str should be a String or if the String should be a &str.