Maybe-sized RPIT type is unexpectedly allowed in `async fn`

[obi1kenobi]

I tried this code: playground

use std::fmt::Debug;

fn breaks() -> impl Debug + ?Sized {
    123
}
//
// error[E0277]: the size for values of type `impl Debug + ?Sized` cannot be known at compilation time
//  --> src/lib.rs:3:16
//   |
// 3 | fn breaks() -> impl Debug + ?Sized {
//   |                ^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
//   |
//   = help: the trait `Sized` is not implemented for `impl Debug + ?Sized`
//   = note: the return type of a function must have a statically known size

async fn works() -> impl Debug + ?Sized {
    123
}
// no error!

I expected to see this happen: return types must always be sized, so -> impl Debug + ?Sized is not valid for any function regardless if it's async or not.

Instead, this happened: the compiler unexpectedly accepts it for async functions.

Meta

rustc --version --verbose:

rustc 1.91.1 (ed61e7d7e 2025-11-07)
binary: rustc
commit-hash: ed61e7d7e242494fb7057f2657300d9e77bb4fcb
commit-date: 2025-11-07
host: x86_64-unknown-linux-gnu
release: 1.91.1
LLVM version: 21.1.2

Also happens on the 2025-11-27 nightly on the playground.

[theemathas]

I even found a way to call and use the output of this function. (More straightforward ways of doing this makes the compiler complain that the return value isn't sized.)

use std::fmt::Debug;

#[tokio::main]
async fn main() {
    wut(works()).await;
}

async fn works() -> impl Debug + ?Sized {
    123
}

async fn wut<T: Future<Output: Debug>>(fut: T) {
    let q = fut.await;
    println!("{q:?}");
}

This compiles and prints 123.

[jhpratt]

For context:

impl Future<Output = impl Debug + ?Sized> is also accepted, though manually implementing Future requires the Sized bound is upheld (as it doesn't opt out of the bound). Similarly, Poll<T> does not opt out, so it requires the type (returned by fn poll) to be sized.

While this probably should be rejected, simple attempts to use this method still errors. (playground)

async fn foo() {
    works().await;
}

   Compiling playground v0.0.1 (/playground)
error[E0277]: the size for values of type `impl Debug + ?Sized` cannot be known at compilation time
  --> src/lib.rs:21:5
   |
21 |     works().await;
   |     ^^^^^^^^^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `Sized` is not implemented for `impl Debug + ?Sized`
   = note: all local variables must have a statically known size

error[E0277]: the size for values of type `impl Debug + ?Sized` cannot be known at compilation time
  --> src/lib.rs:21:13
   |
21 |     works().await;
   |             ^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `Sized` is not implemented for `impl Debug + ?Sized`
note: required by an implicit `Sized` bound in `Poll`
  --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/task/poll.rs:14:15
   |
14 | pub enum Poll<T> {
   |               ^ required by the implicit `Sized` requirement on this type parameter in `Poll`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` (lib) due to 2 previous errors

Though as I'm about to post this, I'm sniped and proven that this can in fact be called. It takes some effort, at least.

[fmease]

jhpratt has pretty much sussed it out. There are situations in which we currently don't check whether the RHS of an associated type binding (projection predicate) of/for an RPIT satisfies the so-called item bounds of the associated type.

Rephrased, there are times where we fail to validate that the Ty in impl Trait<AssocTy = Ty> satisfies Bound0 + Bound1 + … from trait Trait { type AssocTy: Bound0 + Bound1 + …; }.

What's interesting, we have a warn-by-default lint for this: opaque_hidden_inferred_bound (seemingly no tracking issue & meant to be a future-incompat lint). However, it doesn't trigger in this case where we have nested RPITs! See for yourself: Replace the TAIT from the lint example with a nested RPIT (Tait→impl Sized, remove the attr & the ty alias) and the warning goes away.

Side note: This issue doesn't just arise with nested TAITs/RPITs. I also found fn f(x: impl Iterator<Item = str>) -> impl Iterator<Item = str> { x } (which thankfully does trigger the lint), however it doesn't really count since it exploits a separate issue where we don't validate the RHS of assoc ty bindings of/for certain bounds (is that tracked anywhere?)

[Aditya-PS-05]

@rustbot claim

[lcnr]

@Aditya-PS-05 do you have some plan for how to fix this issue? This is quite entangled with how opaque types and associated type constraints are handled in general, so even I don't have a good grasp of what should be done here.