Parser should allow construction from in-memory bitcode

[swernli]

Currently, the pyqir_parser only supports initializing the parser from a string that contains the path to an on-disk bitcode file. It would be helpful to support constructing a parser instance from an in-memory bitcode file, as that would open up more scenarios where code is already actively operating on bitcode, such as receiving it as a network stream.

Note that this may require updates to the underlying llvm_ir module that the parser depends on.

[LaurentAjdnik]

Indeed, llvm_ir only provides a from_bc_path(path) function. ☹️

The source code relies on LLVMCreateMemoryBufferWithContentsOfFile() then LLVMParseBitcodeInContext2() (both from the llvm-sys crate) before calling Self::from_llvm_ref().

In order not to update the llvm_ir code, could we somehow (Rust definitely isn't my universe...) inherit / compose / embed / extend / encapsulate the Module struct and add a from_bc(buffer) function, with calls to only LLVMParseBitcodeInContext2() and Self::from_llvm_ref()?

[swernli]

@LaurentAjdnik Given which traits and implementations are pub vs pub(crate) (Rust's rough equivalent to "internal"), this isn't something we can easily extend from the outside. The best bet would be contributing this as new functionality to llvm_ir directly. I don't think that code would be difficult to write, but we'd have to see if they are willing to take it and publish an update the crate.

[cgranade]

but we'd have to see if they are willing to take it and publish an update the crate.

In the most extreme case, may be able to specify a [patch] section in Cargo.toml. It sounds like we're in precisely one of the intended usecases:

• You've submitted a fix to an upstream crate for a bug you found, but you'd like to immediately have your application start depending on the fixed version of the crate to avoid blocking on the bug fix getting merged.