How to get detailed analysis for unsatisfied Trait bounds

[omarabid]

I am not sure if this is possible or not but I spent some time trying to figure out where my bounds were not satisfied. I wonder if the compiler can already do this matching.

The code is a bit complex to get it separated but here is the bit that matters

let octocrabi = octocrab::OctocrabBuilder::new_empty()
                .with_service(client)
                .with_layer(&BaseUriLayer::new(http::Uri::from_static(
                    "https://api.github.com",
                )))
                .with_auth(auth)
                .build()?;

This code fails to compile because build is only available when auth is AuthState. That's cool, except that the message the compiler outputs is the following

error[E0599]: no method named `build` found for struct `OctocrabBuilder<BaseUri<TReq>, NoConfig, Auth, LayerReady>` in the current scope
   --> src/lib.rs:189:40
    |
189 |             .build()?;
    |                      ^^^^^ method not found in `OctocrabBuilder<BaseUri<TReq>, NoConfig, Auth, LayerReady>`
    |
    = note: the method was found for
            - `OctocrabBuilder<Svc, NoConfig, AuthState, LayerState>`

Now you might looking at this and say that the type AuthState is expected and I am providing Auth but this is only obviously after the fact. During the debugging process, you are wondering whether it's LayerState, or Svc. It's not clear from the error message which one is responsible for this.

Any ways to make this clearer?

[quinedot]

Reproduction approximation.

My take is that you don't get an analysis of unsatisfied trait bounds because there is no build for

OctocrabBuilder<_, _, Auth, _>

Just for^[1]

//              Has bounds                No bounds
// Generics:    vvv                       vvvvv
OctocrabBuilder<Svc, NoConfig, AuthState, Layer>

// (None are generic)
OctocrabBuilder<NoSvc, DefaultOctocrabBuilderConfig, NoAuth, NotLayerReady>

That is, because all the implementations adding fn build have a concrete type in the third type parameter position, which is not Auth.

I don't think it gets as far as checking bounds, since there are no applicable implementations.

The diagnostic would be more clear if it pointed out what were concrete types and what were generics in the "method was found for" list somehow, IMO. And even better if it could highlight that Auth in particular didn't match any implementations, since none had a generic in that position.^[2]

---

1. Assuming I got the right crate and version. ↩︎

2. I didn't dig deep enough to tell if BaseUri<TReq> satisfies the bounds on the implementation. ↩︎