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

Compile-time closure freeze checking #4

Open
chc4 opened this issue Sep 12, 2021 · 1 comment
Open

Compile-time closure freeze checking #4

chc4 opened this issue Sep 12, 2021 · 1 comment
Labels
good first issue Good for newcomers

Comments

@chc4
Copy link
Owner

chc4 commented Sep 12, 2021

There's a section in the README about the hypothetical freezing allocator we can use to make sure closure environments are safe to inline by forcing them to be immutable (at the cost of runtime segfaults...)

We can actually do slightly better, and put off implementing that for a bit: Rust has automatic marker traits like Send and Sync that are implemented for any type that only contains fields already marked with that trait. The Rust compiler has an internal marker trait Freeze that's used for marking interior immutability - which is the exact same thing we care about. Magically, marker traits are also implemented for Fn trait objects automatically too, so we can 1) verbatim copy Freeze out of the stdlib (or maybe use https://crates.io/crates/freeze-macros which seems to do exactly that??) 2) change Jit::speedup<F> to be Jit::speedup<F: Freeze> to only accept closures that are interior immutable. This gives us compile-time errors instead of runtime segfaults, which is a bonus.

@chc4
Copy link
Owner Author

chc4 commented Feb 17, 2022

I removed the freezing part from the readme, since we'd probably implement the marker trait solution along with whatever initial implementation, and there's no reason to lie about the freezing design if it isn't even implemented yet.

4a104c9#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L56 is a hotlink to it, for posterity.

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

No branches or pull requests

1 participant