Mismatch between sync and async drop gen?

[lovely-error]

I expect that the async version would panic at compile time the same way sync version does

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=4b0f956255c35cca27761291affcda87

[workingjubilee]

headscratch

...cc @azhogin? Sorry if this isn't in your bailiwick.

[moxian]

This seems to have little to do with async drop gen, and is more about const eval, and how it handles async (and monomorphization, and visibility.. I think..). Consider:

// assuming --crate-type=lib , i.e. this is src/lib.rs
struct CantMake<T>{inner: T}
impl<T> CantMake<T>{
    fn new(x: T) -> Self{
        const { panic!("wanted to make unmakable") }
    }
}
struct CantDrop<T>{inner: T}
impl<T> CantDrop<T>{
    fn new(x: T) -> Self{
        Self{ inner: x }
    }
}
impl<T> std::ops::Drop for CantDrop<T>{
    fn drop(&mut self){
        const { panic!("wanted to drop undroppable") }
    }
}

// compiles
fn sync_private() {
    let _a_sync_private = CantMake::new(0_u8);
    let _a_sync_private = CantDrop::new(1_u8);
}
// fails to compile
pub fn sync_public() {
    let _a_sync_public = CantMake::new(2_u8);
    //~^ ERROR: evaluation of `CantMake::<u8>::new::{constant#0}` failed
    let _b_sync_public = CantDrop::new(3_u8);
    //~^ ERROR: evaluation of `<CantDrop<u8> as std::ops::Drop>::drop::{constant#0}` failed
}
// compiles
pub async fn async_public() {
    let _a_async_public = CantMake::new(4_u8);
    let _b_async_public = CantDrop::new(4_u8);
}

Note that trying to actually invoke async_public like so:

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

does result in the const eval errors, for both constructor and drop.

(I don't know enough about const eval to speculate whether the status quo is desirable)

@rustbot label: +A-const-eval +A-async-await +T-compiler +A-monomorphization

[moxian]

See also: #111202 and (tangentially) #122814

[saethlin]

Talking about private/public is probably a distraction from the point of this issue. Same with optimizations.

The "I expected this to panic at compile time" program can be reduced to this:

#![crate_type = "lib"]

fn impossible<T>() {
    const { panic!() }
}
pub fn public() -> impl Fn() {
    || impossible::<u8>()
}

(remember that async fn doesn't execute the body when called, it returns a state machine that must be polled to execute the body)

MentionedItems only looks into terminators. The closure (or coroutine in the case of async) only appears in an assignment from an Rvalue::Use, so we never recurse into the body of the closure inside public to find const { panic!() }.

I don't know if the current behavior is intentional or desirable. Just clearing up that this has nothing to do with async.

[moxian]

I disagree though, this has a whole lot to do with async.

However, looking closer there are two different problems in a trenchcoat here. One about monomorphization (but not async), the second about async (but not monomorphization). I've split the latter into #140655 to keep the issue focused.
Thanks for the minimization of the mono part, this is great!