Dan Kolsoi comments

Results 206 comments of


                                            Dan Kolsoi

The cloned instructions always lose information on their names and parent basic blocks

I'm not sure I follow - your example code doesn't call Clone on the instruction and neither does `into_instruction_value`. Where is this clone occurring, exactly?

Can't get JitFunction for function that takes arguments involving lifetimes

Does this work if you do `type FuncType

Can't get JitFunction for function that takes arguments involving lifetimes

You're correct that they're not equivalent, but I actually think the non HRTB might be the correct approach here - or at least I don't think there is any way...

Can't get JitFunction for function that takes arguments involving lifetimes

Imagine trying to call the HRTB function, I think you'd want to be able to specify the lifetime in the struct? Making it work for all possible lifetime values doesn't...

Can't get JitFunction for function that takes arguments involving lifetimes

In any case, I suspect this is a limitation of Rust and not inkwell

View function disassembly or raw instructions?

I'm not certain you can do the former at the moment. For the latter, maybe ~`Module::parse_bitcode_from_buffer`~ `Context::create_module_from_ir`? I don't think you can just inject IR into the module other than...

Undefined behavior with `MemoryBuffer::create_from_memory_range`

Good find, thanks!

`test_object_file::test_symbol_iterator` triggers assert in llvm 10

Agreed - I think marking it unsafe and adding documentation is better than removing it altogether.

`test_object_file::test_symbol_iterator` triggers assert in llvm 10

Though it's a shame the C API lacks a symbol check

unsafe to get or set thread_local_mode on a function

I'd rather not split up `GlobalValue` and `GlobalVariable` because they're so similar and I don't want to further conflate inkwell's API. What if we just have `get_thread_local_mode` return `None` if...