allow opaque_hidden_inferred_bound warning on nightly

[hawkw]

Currently, our nightly builds are failing due to the new warning opaque_hidden_inferred_bound, which triggers when an opaque type (impl Trait) in an associated type position does not explicitly include the associated type's trait bounds (e.g. returning a Service<Future = impl Send, ...>) or similar.

Unfortunately, we cannot simply change our code to make the trait bound's type explicit, as changing impl Send to
impl Future<...> + Send in this position results in a surprising error which I don't think is correct:

error[E0277]: `impl std::marker::Send` is not a future
  --> linkerd/app/outbound/src/http/logical.rs:97:30
   |
97 |                     Future = impl Future<Output = Result<http::Response<http::BoxBody>, Error>> + Send,
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `impl std::marker::Send` is not a future
   |
   = help: the trait `futures::Future` is not implemented for `impl std::marker::Send`
   = note: impl std::marker::Send must be a future or must implement `IntoFuture` to be awaited
   = note: required for `stack::map_err::ResponseFuture<(), impl std::marker::Send>` to implement `futures::Future`

For more information about this error, try `rustc --explain E0277`.

See #2268 (comment) for details.

This should probably be reported on the Rust issue tracker, since a warning that's (apparently) impossible to fix seems not great. However, for now, we can simply allow this warning for our nightly builds.

This should fix CI.

[mateiidavid]

Unfortunately, we cannot simply change our code to make the trait bound's type explicit, as changing impl Send to
impl Future<...> + Send in this position results in a surprising error which I don't think is correct:

Am I understanding this right? So basically, we have a Send bound on the associated type, and if we use an associated type that uses impl Future (so whatever opaque type that implements Future), and we add that this type has a Send bound, it won't work?

Also, just curious but how come we use an opaque type (impl Send) instead of just specifying a bound Send on it for more flexibility? Sorry bit besides the point, but while I'm here... 🤷🏻

[olix0r]

FYI, i believe this change is also included in Rust 1.66; so we may need a more robust change than changing the nightly workflow.

[hawkw]

@mateiidavid

Unfortunately, we cannot simply change our code to make the trait bound's type explicit, as changing impl Send to
impl Future<...> + Send in this position results in a surprising error which I don't think is correct:

Am I understanding this right? So basically, we have a Send bound on the associated type, and if we use an associated type that uses impl Future (so whatever opaque type that implements Future), and we add that this type has a Send bound, it won't work?

I think what you're describing here is kind of backwards: we have an associated type where the trait bounds the associated type with Future:

pub trait Service {
     type Future: Future<Output = Result<Self::Response, Self::Error>>;
    // ...
}

and here, we are returning a Service and saying that the Future type is impl Send, to indicate that the future is also Send:

fn stuff() -> impl Service<
    Future = impl Send,
    // ...
> {
    // ...
}

Since Service bounds its Future associated type with the Future trait, the impl Service's Future associated type is already required to implement Future. We don't need to return impl Future there, although the opaque_hidden_inferred_bound lint asks us to add it (presumably for explicitness)

Also, just curious but how come we use an opaque type (impl Send) instead of just specifying a bound Send on it for more flexibility? Sorry bit besides the point, but while I'm here... 🤷🏻

We use an opaque type in return type position --- trait bounds constrain generic type parameters, which are (generally) inputs to a function¹; we cannot add trait bounds to a return type that a function determines on its own. Instead we return opaque types (impl Traits) to say "this function returns 'something' which implements these traits".

Footnotes

1. a function can return one of its type parameters, but it isn't responsible for determining what type that value is --- type parameters are types determined by the caller, while opaque types (impl Trait) are determined by the returner. If that makes sense... ↩

[hawkw]

FYI, i believe this change is also included in Rust 1.66; so we may need a more robust change than changing the nightly workflow.

Yeah...we'll have to address that separately when we actually update our compiler version to 1.66, though, because adding -A opaque_hidden_inferred_bound will cause a compiler error on compiler versions that don't know about that lint.