wrbs opened Issue #2738:
In #1184 and #1214
cranelift-module
was extended to add support for passing in a trap sink while compiling a function. However there's no support for doing the same with aStackMapSink
and it looks like at the time this was deferred to later.I'm interested in using the GC support for something which would use the
cranelift-jit
interface but there's currently no way to access stackmaps when doing that.I'm not sure what the best way to fix this is. One method could be adding a
stack_map_sink: &mut dyn StackMapSink
argument todefine_function
but that would require all users of the interface (most of who don't use stack maps) to pass in a&mut NullStackMapSink {}
in the same way as passing aNullTrapSink
is required. However if breaking changes to the API are ok this fits the existing convention.I'm thinking of sending a PR with this approach but I'd like to know if this is acceptable.
pchickey commented on Issue #2738:
That sounds like a fine approach - please do send a PR!
pchickey closed Issue #2738:
In #1184 and #1214
cranelift-module
was extended to add support for passing in a trap sink while compiling a function. However there's no support for doing the same with aStackMapSink
and it looks like at the time this was deferred to later.I'm interested in using the GC support for something which would use the
cranelift-jit
interface but there's currently no way to access stackmaps when doing that.I'm not sure what the best way to fix this is. One method could be adding a
stack_map_sink: &mut dyn StackMapSink
argument todefine_function
but that would require all users of the interface (most of who don't use stack maps) to pass in a&mut NullStackMapSink {}
in the same way as passing aNullTrapSink
is required. However if breaking changes to the API are ok this fits the existing convention.I'm thinking of sending a PR with this approach but I'd like to know if this is acceptable.
Last updated: Dec 23 2024 at 12:05 UTC