Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any::downcast_ref fails on closures across crates #34758

Closed
willcrichton opened this issue Jul 10, 2016 · 1 comment
Closed

Any::downcast_ref fails on closures across crates #34758

willcrichton opened this issue Jul 10, 2016 · 1 comment

Comments

@willcrichton
Copy link
Contributor

willcrichton commented Jul 10, 2016

Minimal example: https://github.com/willcrichton/issue-34758

If I have a create a value of type Box<Any> which is an upcasted version of a closure (e.g. Fn()) in one crate and then downcast it with the appropriate type in another crate, it fails. For example, if I have the following library in one crate:

use std::any::Any;

pub fn alloc<T: Any>(t: T) -> Box<Any> {
    Box::new(t)
}

pub fn unwrap<T: Any>(x: Box<Any>) {
    x.downcast_ref::<T>().unwrap();
}

pub fn unwrap_i32(x: Box<Any>) {
    x.downcast_ref::<i32>().unwrap();
}

pub fn unwrap_closure(x: Box<Any>) {
    x.downcast_ref::<Box<Fn()>>().unwrap();
}

And then a binary that uses the library in another crate:

extern crate lib;

mod lib_incrate {
    use std::any::Any;

    pub fn alloc<T: Any>(t: T) -> Box<Any> {
        Box::new(t)
    }

    pub fn unwrap_closure(x: Box<Any>) {
        x.downcast_ref::<Box<Fn()>>().unwrap();
    }
}

fn main() {
    let x: i32 = 1i32;
    lib::unwrap::<i32>(lib::alloc(x));

    let x: i32 = 1i32;
    lib::unwrap_i32(lib::alloc(x));

    let x: Box<Fn()> = Box::new(||{});
    lib::unwrap::<Box<Fn()>>(lib::alloc(x));

    let x: Box<Fn()> = Box::new(||{});
    lib_incrate::unwrap_closure(lib_incrate::alloc(x));

    println!("Fails here?");
    let x: Box<Fn()> = Box::new(||{});
    lib::unwrap_closure(lib::alloc(x));
}

Then it fails where noted (i.e. at the unwrap).

@willcrichton
Copy link
Contributor Author

willcrichton commented Jul 10, 2016

Never mind, just a duplicate of 33703.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant