`rust-analyzer` throwing out errors on complex traits but `rustc ` compiling without issues

community
1

Hi everyone!

When writing Tower services for my app (possibly when chaining multiple of them) I get a return type mismatch error from rust-analyzer but no issues from rustc.

Since rustc compiles my code perfectly fine, I assume this is a limitation in how ⁠rust-analyzer⁠ resolves deeply nested ⁠Tower⁠ traits (not dealing correctly with complex trait bounds), rather than an issue with my code.

  1. Is this a known limitation of rust-analyzer or a big oversight from my part?
  2. How could the trait be rewritten to avoid rust-analyzer complaints?

Thanks in advance!

rustc: 1.96.0
rust-analyzer: 0.3.2955

PS: This is an extensible microservices framework.

2

RA uses the next-gen trait solver already, so this could be related. If you get the same error on nightly with -Z next-solver=globally and think it's a bug, you could file a bug report (or look for an existing one that seems the same).

3

This could be a next-solver issue like @quinedot has said. It could also be a recursion limit issue; rust-analyzer hardcodes the recursion limit to 50, which is lower than rustc's default 128 and cannot be customized.

4

Yes, it could be, but if it was a recursion limit issue, wouldn't rust-analyzer indicate a recursion limit?

5

I will try the nightly compiler!

6

This is the exact RA error:
expected Pin<Box<dyn Future<Output = Result<ExecuteResponse, Error>> + Send + 'static, Global>>, found Pin<Box<impl Future<Output = Result<ExecuteResponse, RequestError>>, Global>> where type Error = InnerService::Error; (which is RequestError).
I don't know whether this issue is related Conversion of generated future fails, although it should succeed · Issue #92929 · rust-lang/rust · GitHub

7

Interesting, when using nightly on 1.99.0-nightly and RA 0.3.2963-standalone the issue disappears without using -Z next-solver=globally.

8

No, r-a does not emit a diagnostic when the recursion limit is reached for trait solving.

9

Thanks everyone for all your help! At the moment I think I will stick with the stable rustc and RA while the nightly build fixes the trait issue, it unfortunately causes RA to panic on some proc_macros. I'm looking forward to the stabilization of 1.99!

10

Have you tried compiling using cargo build --test as that is what RA gets its analysis from?

11

That is incorrect. rustc gets diagnostic from cargo check (if you have check on save enabled), which can cause errors even if it is clean on the terminal due to different flags, but most of the time not, and r-a own analysis, which is totally independent of Cargo and rustc.

12

oh - i though that it was dependent on rustc/cargo's test tool? have they built one themselves?

13

r-a does depend on Cargo for few things. For example, discovering workspaces, running check on save, or running tests when requested by the user. None of them can emit a trait error except check on save, and as I said it is likely not involved here.