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

Moving a JsObject inside a closure causes a panic #1515

Closed
jedel1043 opened this issue Aug 25, 2021 · 2 comments · Fixed by #1518
Closed

Moving a JsObject inside a closure causes a panic #1515

jedel1043 opened this issue Aug 25, 2021 · 2 comments · Fixed by #1518
Labels
bug Something isn't working
Milestone

Comments

@jedel1043
Copy link
Member

Describe the bug
Currently moving any Gc<T> inside a closure causes a panic. This issue comes from Manishearth/rust-gc#50, and it doesn't seem like it will get fixed until there's some API for garbage collectors in rustc.
However, we currently allow moving JsObjects and JsValues inside closures, which causes a panic on destruction.

To Reproduce

use boa::{Context, JsValue};

fn main() -> Result<(), JsValue> {
    let mut context = Context::new();

    let object = context.construct_object();

    let moved_object = object.clone();

    context.register_global_closure("closure", 0, move |_, _, _| {
        // This value is captured from main function.
        moved_object.is_array();
        Ok(JsValue::Undefined)
    })?;

    Ok(())
}

Additional comments
Should we restrict closures to only Fn(..) + Copy? Or should we allow any Fn and document that moving a JsObject into a closure causes a panic?
Maybe we could even make all closures Fn(..) + Copy and ask the user to pass a Captures type, then we change the definition of our closures to Fn(&JsValue, &[JsValue], &mut Closure, Box<dyn Any>) and ask the user to downcast the dyn Any to the type of its Captures. This allows maximum flexibility because the user can pass JsValue and JsObject, but it's also not very ergonomic.

@jedel1043 jedel1043 added the bug Something isn't working label Aug 25, 2021
@Razican
Copy link
Member

Razican commented Aug 25, 2021

@HalidOdat does it make sense to not have the register_global_closure() API for 0.13?

@jedel1043
Copy link
Member Author

I forgot to mention this blocks the implementation of Arguments Mapped exotic objects, because to create one we need to capture the current Environment in a closure and save that closure inside the object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants