Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

E0191: "help: specify the associated type" suggested where this would be wrong #91997

Closed
jendrikw opened this issue Dec 16, 2021 · 6 comments · Fixed by #127094
Closed

E0191: "help: specify the associated type" suggested where this would be wrong #91997

jendrikw opened this issue Dec 16, 2021 · 6 comments · Fixed by #127094
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` A-trait-objects Area: trait objects, vtable layout D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jendrikw
Copy link
Contributor

jendrikw commented Dec 16, 2021

Given the following code: play

trait MyIterator : Iterator {}

fn main() {
    let _ = MyIterator::next;
    //let _ = MyIterator<Item=()>::next;
}

The current output is:

error[E0191]: the value of the associated type `Item` (from trait `Iterator`) must be specified
 --> src/main.rs:4:13
  |
4 |     let _ = MyIterator::next;
  |             ^^^^^^^^^^ help: specify the associated type: `MyIterator<Item = Type>`

But when when I write let _ = MyIterator<Item=()>::next;, it gets interpreted as comparison expressions like (MyIterator < Item) = (() > ::next) and it fails to compile with a lot of "cannot find value Item in this scope" and "cannot find crate next in the list of imported crates". The suggestion is confusing because it is unclear how to apply it.

The error goes away if you use Iterator directly: let _ = Iterator::next; produces the error one would expect:

error[E0283]: type annotations needed for `for<'r> fn(&'r mut Self) -> Option<<Self as Iterator>::Item>`
  --> src/main.rs:2:13
   |
2  |     let _ = Iterator::next;
   |         -   ^^^^^^^^^^^^^^ cannot infer type
   |         |
   |         consider giving this pattern the explicit type `for<'r> fn(&'r mut Self) -> Option<<Self as Iterator>::Item>`, with the type parameters specified
   |
   = note: cannot satisfy `_: Iterator`
note: required by `std::iter::Iterator::next`
@jendrikw jendrikw added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 16, 2021
@BGR360
Copy link
Contributor

BGR360 commented Dec 21, 2021

I think it gets evaluated as an expression because you are missing a ::. If you add them, then you get a new error message (play):

trait MyIterator : Iterator {}

fn main() {
    let _ = MyIterator::<Item=()>::next;
}
error[E0783]: trait objects without an explicit `dyn` are deprecated
 --> src/main.rs:4:13
  |
4 |     let _ = MyIterator::<Item=()>::next;
  |             ^^^^^^^^^^^^^^^^^^^^^ help: use `dyn`: `<dyn MyIterator::<Item=()>>`

@jendrikw
Copy link
Contributor Author

I see, let me rephrase the issue:

The suggestion is "help: specify the associated type: MyIterator<Item = Type>" where "help: specify the associated type: MyIterator::<Item = Type>" with a double colon would be correct.

@fmease fmease added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. A-trait-objects Area: trait objects, vtable layout labels Jun 14, 2024
@fmease
Copy link
Member

fmease commented Jun 14, 2024

Triage: Suggestion is correct for code using dyn (which all code written in Rust >=2021 uses).
For code written without dyn in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).

@Borgerr
Copy link
Contributor

Borgerr commented Jun 28, 2024

@rustbot claim

Borgerr pushed a commit to Borgerr/rust that referenced this issue Jun 28, 2024
@Borgerr
Copy link
Contributor

Borgerr commented Jun 28, 2024

Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.

@fmease
Copy link
Member

fmease commented Jun 28, 2024

Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.

Yeah, it's a pretty easy one. Adding :: before <...> is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., fn f(_: Option::<u32>) {}) — albeit redundant.

#91997 (comment):

As mentioned, the suggestion should use an expression-style path

Omitting :: before <...> in type contexts would be a possible "optimization". However, it really isn't worth doing here. Consider the following code which is ill-formed even after specifying the assoc ty.

//@ edition: 2015
trait MyIterator: Iterator {}

fn main() {
    let _: MyIterator::Item;
}

MyIterator<Item = ()>::Item (<dyn MyIterator<Item = ()>>::Item) would only be well-formed if we defined an inherent associated type Item (#8995) on dyn MyIterator which doesn't work yet anyway (#106719) and is pretty niche) or once™ we support arbitrary shorthand projections (#22519).

Borgerr added a commit to Borgerr/rust that referenced this issue Jul 1, 2024
Borgerr added a commit to Borgerr/rust that referenced this issue Jul 7, 2024
@bors bors closed this as completed in a7fe30d Jul 10, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jul 10, 2024
Rollup merge of rust-lang#127094 - Borgerr:E0191-suggestion-correction, r=fmease

E0191 suggestion correction, inserts turbofish

closes rust-lang#91997
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` A-trait-objects Area: trait objects, vtable layout D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants