Compiler suggests to add [closure@…] to source code when it can be inferred instead.

[vi]

Unminimized example:

error[E0283]: type annotations needed
   --> crates/websocat-ioless/src/lib.rs:346:27
    |
346 |                 let w = w.sink_map_err(|e : std::io::Error |e.into());
    |                           ^^^^^^^^^^^^
    |
    = note: multiple `impl`s satisfying `BytesCodec: Encoder<_>` found in the `tokio_util` crate:
            - impl Encoder<BytesMut> for BytesCodec;
            - impl Encoder<websocat_api::bytes::Bytes> for BytesCodec;
    = note: required for `FramedWrite<Pin<Box<dyn tokio::io::AsyncWrite + std::marker::Send>>, BytesCodec>` to implement `websocat_api::futures::Sink<_>`
help: try using a fully qualified path to specify the expected types
    |
346 |                 let w = <FramedWrite<Pin<Box<dyn tokio::io::AsyncWrite + std::marker::Send>>, BytesCodec> as SinkExt<Item>>::sink_map_err::<websocat_api::anyhow::Error, [closure@crates/websocat-ioless/src/lib.rs:346:40: 346:61]>(w, |e : std::io::Error |e.into());
    |                         +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ~

(in vi/websocat@9ef27b9, caused by upgrade from tokio-util 0.6 -> 0.7)

And I'm not sure how do I explicitly choose the impl I want when it is buried deep in third-party generics.

Aren't coherence rules designed to prevent this by the way?

The diagnostic is useful, but contains a lot of types that can be inferred instead, including the closure type. <_ as SinkExt<bytes::Bytes>>::sink_map_err makes it compile. It would be better if code suggestion preserved as much reliance on the type inference as possible.

rustc 1.66.0-nightly (0da281b60 2022-10-27).

[vi]

Sorry, the got confused by the closure and not recognized the <... as ...>:: syntax and that it suggested me to switch to UFCS.

Would be simpler if error message was minimized by omitting details that are not relevant to the the ambiguity and can continue to be inferred instead.

[fmease]

The compiler should never suggest to you to write [closure@…] since that's not valid syntax. Could you please re-open the issue, @vi :)

@rustbot label C-bug A-suggestion-diagnostics D-invalid-suggestion E-needs-mcve

[vi]

Simpler example producing similar message:

trait MyTrait<T> {
   fn lol<F:FnOnce()>(&self, f:F) -> u16;
}

struct Qqq;

impl MyTrait<u32> for Qqq{
   fn lol<F:FnOnce()>(&self, _f:F) -> u16 { 5 }
}
impl MyTrait<u64> for Qqq{
   fn lol<F:FnOnce()>(&self, _f:F) -> u16 { 6 }
}

fn main() {
    let q = Qqq;
    q.lol(||());
}

error[E0282]: type annotations needed
  --> src/main.rs:16:7
   |
16 |     q.lol(||());
   |       ^^^
   |
help: try using a fully qualified path to specify the expected types
   |
16 |     <Qqq as MyTrait<T>>::lol::<[closure@src/main.rs:16:11: 16:13]>(&q, ||());
   |     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ~

error[E0283]: type annotations needed
  --> src/main.rs:16:7
   |
16 |     q.lol(||());
   |       ^^^
   |
note: multiple `impl`s satisfying `Qqq: MyTrait<_>` found
  --> src/main.rs:7:1
   |
7  | impl MyTrait<u32> for Qqq{
   | ^^^^^^^^^^^^^^^^^^^^^^^^^
...
10 | impl MyTrait<u64> for Qqq{
   | ^^^^^^^^^^^^^^^^^^^^^^^^^
help: try using a fully qualified path to specify the expected types
   |
16 |     <Qqq as MyTrait<T>>::lol::<[closure@src/main.rs:16:11: 16:13]>(&q, ||());
   |     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ~

[estebank]

We could create a new type folder that takes any closure type and replaces it with at minimum a _ and ideally a correct Fn* signature.