Null
Null
> Could this be resolved by making our own wrapper? > > It seems like rustc does something similar with rustc_llvm, where it adds a bunch of extension methods that...
@jaynus, if you ever get around to finishing this up, I just want to apologize for creating a merge conflict. You see, I thought your idea of using the `OperandValue`...
Sorry about the missing label, I'm not sure how to add it.
At first, I was working on Orc JIT in an experimental repo. It made me realize that there might be someone that would want to implement their own extensions to...
> In general I've started opening up types' new methods to be public, but it's not clear to me how that would be useful for LLVMString - the type's intention...
Oh, I almost forgot. There's also a problem with Eager compilation that I believe is a Windows problem. External symbols from modules aren't exported for resolution, which means that if...
That can be a difficult thing to work around, since that means that users will be expected to keep the context that created the module alive while the Orc Engine...
I don't actually think it would be a problem to move `ContextImpl` into an `Arc` inside of `Context`, since `Context` isn't `Clone` nor `Copy`. Then `Module` could own an `Arc`...
One problem would be the `create_builder` and `create_module` functions in `ContextImpl`, they wouldn't have an `Arc` to pass to the `Module` nor `Builder`.
Oh, and to answer your question, moving the context into the OrcEngine is one option, but then you wouldn't be able to use that context anymore. Another option is to...