You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, rustc_trans::abi uses LLVM, which makes it hard to use from alternate back-ends like Cranelift. If we refactor it to a separate crate that only relies on ty::layout, that would make life easierr.
cc @eddyb.
cc @camlorn - you might be interested in it.
The text was updated successfully, but these errors were encountered:
This seems like a good idea but also like a really huge project, so have fun with it.
I'm not actually sure what all that module does. My work barely touched it. I doubt I'll be much use here, but I'll certainly monitor. One thing that would be nice to have (and that this may help with) is a C backend, which would have potential uses for things like integrating with Python (which can only compile C). Maybe someone already did that, though.
Most of it is in #40658 already, but I want to keep this issue open for tracking the move to a different crate.
I'm pretty sure we can do it by having generics over the Ty in TyLayout (and/or the context type), but keep Layout fully defined outside of librustc.
Currently,
rustc_trans::abi
uses LLVM, which makes it hard to use from alternate back-ends like Cranelift. If we refactor it to a separate crate that only relies onty::layout
, that would make life easierr.cc @eddyb.
cc @camlorn - you might be interested in it.
The text was updated successfully, but these errors were encountered: