False E0282 and unknown types for `zenoh::Session::get`

rust-analyzer version: rust-analyzer 0.4.3018-standalone

Also reproduced with 0.3.3016-standalone, 0.3.3008-standalone, and 0.3.2997-standalone.

rustc version: rustc 1.97.1 (8bab26f4f 2026-07-14)

editor or extension: VS Code with rust-lang.rust-analyzer extension version 0.4.3018

relevant settings: No rust-analyzer-specific settings. The issue also reproduces outside the editor by invoking the extension's bundled rust-analyzer diagnostics binary directly.

repository link (if public, optional): No public reproduction repository; the complete minimal reproduction is below.

code snippet to reproduce:

Cargo.toml:

[package]
name = "zenoh-ra-repro"
version = "0.1.0"
edition = "2024"

[dependencies]
zenoh = "=1.10.0"
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }

src/main.rs:

#[tokio::main]
async fn main() {
    let session = zenoh::open(zenoh::Config::default()).await.unwrap();
    let replies = session.get("key/expression").await.unwrap();
    while let Ok(reply) = replies.recv_async().await {
        println!(">> Received {:?}", reply.result());
    }
}

Steps to reproduce

1. Create the two files above.
2. Run cargo check; it succeeds without errors.
3. Open src/main.rs in VS Code, or run:

rust-analyzer diagnostics .

Expected behavior

rust-analyzer should infer:

replies: zenoh::handlers::FifoChannelHandler<zenoh::query::Reply>
reply: zenoh::query::Reply

No E0282 diagnostic should be emitted.

Actual behavior

The editor displays unknown for both replies and reply. The standalone diagnostics command emits false E0282 diagnostics:

at crate zenoh_ra_repro, file src/main.rs: Error RustcHardError("E0282") from LineCol { line: 3, col: 18 } to LineCol { line: 3, col: 53 }: type annotations needed
at crate zenoh_ra_repro, file src/main.rs: Error RustcHardError("E0282") from LineCol { line: 4, col: 14 } to LineCol { line: 4, col: 23 }: type annotations needed

cargo check accepts the same source without errors.

Additional context

The suspected trigger is normalization of the nested associated-type projections used by Zenoh's default handler:

SessionGetBuilder<'_, '_, DefaultHandler>
IntoFuture::Output = <Self as Resolvable>::To
Resolvable::To = ZResult<Handler::Handler>
DefaultHandler::Handler = <FifoChannel as IntoHandler<T>>::Handler

rustc resolves the final type to FifoChannelHandler<Reply>, while rust-analyzer appears to leave the projection unresolved.

The following workaround compiles and removes the rust-analyzer diagnostics:

use zenoh::Wait;

#[tokio::main]
async fn main() {
    let session = zenoh::open(zenoh::Config::default()).await.unwrap();
    let replies: zenoh::handlers::FifoChannelHandler<zenoh::query::Reply> =
        session.get("key/expression").wait().unwrap();
    while let Ok(reply) = replies.recv_async().await {
        println!(">> Received {:?}", reply.result());
    }
}

For this builder, IntoFuture::into_future returns Ready around self.wait(), so this workaround does not change the operation's behavior.

Reproduce the report using the supplied Cargo.toml and src/main.rs, first comparing cargo check with rust-analyzer diagnostics. Trace how the nested associated-type projections in Session::get and IntoFuture are normalized. Done means the example infers FifoChannelHandler and Reply without false E0282 diagnostics or unknown types.