Open
Description
Hi there,
we just noticed on warp
CI that one of the examples was broken (we have #![deny(warnings)]
for the examples). The output is as follows:
warning: opaque type `impl warp::Filter + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection> + Clone` does not satisfy its associated type bounds
--> examples/todos.rs:39:22
|
39 | ) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: /home/jxs/dev/oss/warp/src/filter/mod.rs:40:19
|
40 | type Extract: Tuple; // + Send;
| ----- this associated type bound is unsatisfied for `impl Reply`
|
= note: `#[warn(opaque_hidden_inferred_bound)]` on by default
help: add this bound
|
39 | ) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = warp::Rejection> + Clone {
| ++++++++++++++++++++++
warning: opaque type `impl warp::Filter + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection> + Clone` does not satisfy its associated type bounds
--> examples/todos.rs:49:22
|
49 | ) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: /home/jxs/dev/oss/warp/src/filter/mod.rs:40:19
|
40 | type Extract: Tuple; // + Send;
| ----- this associated type bound is unsatisfied for `impl Reply`
|
help: add this bound
|
49 | ) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = warp::Rejection> + Clone {
| ++++++++++++++++++++++
warning: opaque type `impl warp::Filter + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection> + Clone` does not satisfy its associated type bounds
--> examples/todos.rs:60:22
|
60 | ) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: /home/jxs/dev/oss/warp/src/filter/mod.rs:40:19
|
40 | type Extract: Tuple; // + Send;
| ----- this associated type bound is unsatisfied for `impl Reply`
|
help: add this bound
|
60 | ) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = warp::Rejection> + Clone {
| ++++++++++++++++++++++
warning: opaque type `impl warp::Filter + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection> + Clone` does not satisfy its associated type bounds
--> examples/todos.rs:71:22
|
71 | ) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: /home/jxs/dev/oss/warp/src/filter/mod.rs:40:19
|
40 | type Extract: Tuple; // + Send;
| ----- this associated type bound is unsatisfied for `impl Reply`
|
help: add this bound
|
71 | ) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = warp::Rejection> + Clone {
| ++++++++++++++++++++++
warning: opaque type `impl warp::Filter + warp::filter::FilterBase<Extract = impl Reply, Error = Rejection> + Clone` does not satisfy its associated type bounds
--> examples/todos.rs:82:22
|
82 | ) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: /home/jxs/dev/oss/warp/src/filter/mod.rs:40:19
|
40 | type Extract: Tuple; // + Send;
| ----- this associated type bound is unsatisfied for `impl Reply`
|
help: add this bound
|
82 | ) -> impl Filter<Extract = impl warp::Reply + warp::generic::Tuple, Error = warp::Rejection> + Clone {
| ++++++++++++++++++++++
It seems to have been introduced with Rust version 1.66
as with 1.65
the example compiles fine. I also tried with the latest nightly (cargo 1.69.0-nightly (e84a7928d 2023-01-31)
) which still reproduces the problem. This feels like a bug as it being a warning doesn't provide help, btw warp::generic::Tuple
is private.
The todos
example should work as a MRE, but if required I can try to provide a simpler use case.
Thanks!
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
clubby789 commentedon Feb 6, 2023
searched nightlies: from nightly-2022-10-01 to nightly-2023-01-01
regressed nightly: nightly-2022-10-05
searched commit range: f83e026...01af504
regressed commit: 02cd79a
bisected with cargo-bisect-rustc v0.6.5
Host triple: x86_64-unknown-linux-gnu
Reproduce with:
The lint was introduced in #102568
compiler-errors commentedon Feb 6, 2023
Hey, yeah so I authored that warning. Sorry that it's so vague.
So the gist is that
Extract
requires the associate type to implementTuple
, butimpl Reply
doesn't implementTuple
though, at least not the public-facing side of the type. This is code that only compiles due to a hack in the compiler. We could downgrade the lint, I guess, but that just masks the issue that theimpl Filter<...>
still is not "valid".The suggestion kinda sucks, because yeah,
Tuple
is unreachable, but the underlying issue still remains I think.cc @oli-obk, maybe you have additional or different thoughts about this lint.
jonas-schievink commentedon Feb 7, 2023
Hmm, why should code like this be rejected? The caller knows that the opaque type meets the bounds because the bound is on the associated type in the first place (and the function compiles, so whatever type it used there must meet the bound).
If anything it's weird that the equivalent
-> RequiresTuple<impl Reply>
doesn't compile, no? (wherestruct RequiresTuple<T: Tuple>(T);
)oli-obk commentedon Feb 7, 2023
It makes sense from inside the body of the function, but from the outside it is a bit weird:
impl Reply
does not implementTuple
(sinceTuple
is not a super trait ofReply
), so the bound on theRequiresTuple
struct doesn't hold.apiraino commentedon Feb 14, 2023
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-medium
ThomasHabets commentedon Feb 20, 2023
I encountered this warning. Everything seems to be working, but I want to fix the warning.
Could someone explain how to fix this, as if I've only used Rust for a week and this is happening in the first real program I write in it?
compiler-errors commentedon Feb 20, 2023
You can replace
Extract = impl warp::Reply
withExtract = (impl warp::Reply,)
, I think.See: seanmonstar/warp#1020 (comment)
ThomasHabets commentedon Feb 20, 2023
Indeed that gets rid of the warning. Thanks! I would not have guessed this solution.
olix0r commentedon Feb 27, 2023
May I ask why this warning is desirable? Let's say I have a function like
This warning prefers this as:
This feels like needless boilerplate in our application -- it's obvious that the
Future
type attribute has to implementFuture
. Why is it desirable that this be made explicit everywhere the type is referenced?olix0r commentedon Feb 27, 2023
Actually, what I wrote above is not correct. We are apparently unable to satisfy the proper Future bounds?
See @hawkw's comment on linkerd/linkerd2-proxy#2275:
allow `opaque_hidden_inferred_bound` warning on nightly (#2275)
added mvc structure (only controllers and routers);
removed some pub modifiers from internal functions;
Merged in branch 01-hotfix
Merged in branch 01-add-registration-login-mock
Merged in branch 01-add-registration-login-mock
added mvc structure (only controllers and routers);
Merged in branch 01-hotfix
removed some pub modifiers from internal functions;