[LLVMdev] Python bindings available.

[Mahadevan R]

> Consider the case where a function creates and populates a Module, stuffs it
> in an ExistingModuleProvider for the JIT, then returns the ModuleProvider,
> dropping direct reference to the Module. (ModuleProvider takes ownership of
> the Module.) I presume that your Python object is under the impression it
> owns the Module; when that goes out of scope, its refcount goes to zero and
> it invokes its dtor, disposing of the Module. D'oh— now the ModuleProvider
> has a dangling pointer. :)

Ah. Good one. Would the following fix it?

1) Have ModuleProvider maintain a reference to the Module it owns,
     so that the ref count is at least 1 at any time. This is easily done.
     The only thing left is when an MP goes away, the module's dtor
     will be called first, deleting the module, then the MP's dtor will
     be called, which will try to delete the same module again.

2a) So either we can prevent the actual destruction of modules that
    are attached to MPs, or

2b) Do not do anything in the dtors of MPs (while letting the dtor of
    modules do the work)

Both options have the disadvantage of assuming the C/C++ implementation
(like MP::dtor deletes only the module and nothing else).

> The routine LLVMModuleRef
> LLVMGetGlobalParent(LLVMValueRef Global); poses a related problem; in this
> case, the returned reference is non-owning, so you must not dtor it from
> Python.

If I do this:

  m1 = Module.new()
  g1 = m1.add_global_variable(ty, "name")
  m2 = g1.module

will the LLVMModuleRef pointer returned in the last call be the
same as that of m1? If so probably we can get "g1.module" to
return the original object itself.

> The fix, of course, is providing a dispose routine and requiring the user to
> call it, since you can't know what they've done with the pointer.

It'd be much easier to use it without an explicit destruction call.
I'd prefer to do it only if there's absolutely no other go.

Regards,
-Mahadevan.