Yuna Tomida

Maybe one of solution is introducing generic that represents state into `Module` like: ```Rust struct Module { fn drop(&mut self) { if self.owned_by_ee.borrow_mut().take().is_none() { unsafe { LLVMDisposeModule(self.module.get()); } } }...

This issue is closely related to #343 as it's also SEGV issue with already disposed `Module`s. Thus, maybe we also need lifetime refers to "original" `Module` to reduce chances where...

Actually, `BasicBlock` can produce SEGV like: ```Rust let ctx = Context::create(); // basic_block lives longer than module. let basic_block = { let module = ctx.create_module("test"); let fn_type = ctx.f64_type().fn_type(&[], false);...

@taquangtrung I agree with you that multiple lifetime specifiers are complex. Actually single lifetime like this seems to work (I mistakenly think this cannot be compiled when writing comment above...

> Using the generic state vs origin types wont work. They'll solve the double free but not general invalid access if you drop the origin before state. I think aliased...

> The generic type is no longer helpful once you base the lifetime on the module. Maybe it's still usable because the main reason I proposed status type generics was...

I met this bug when following `Kareidoscope` tutorial. In my first implementation, I wrapped compiling procedure like: ```Rust fn compile compiler::Result

I see. It seems to be hard to find out what exactly occurs and I feel like it would be better to make such difference invisible from users by introducing...

Yes, exactly. ```Rust let ctx = Context::create(); // gvalue lives longer than module. let gvalue = { let module = ctx.create_module("test"); let gvalue = module.add_global(ctx.i32_type(), Some(AddressSpace::Const), "global"); // This is...

Nice to hear that! However actually, while using `inkwell` as an dependency of some app it doesn' raise any issue for me, either. I encountered this failures during test of...