search for: llinvokeinst

...s might not be able to handle the pseudo-shared functions like llvm::CallInst::doesNotReturn and llvm::InvokeInst::doesNotReturn. We can't do the naive val does_not_return : [> `CallInst | `InvokeInst] t -> bool Like we can with closed variants: val does_not_return : [< llcallinst | llinvokeinst] t -> bool. Although... what if we just add another variant? This would work: type llcallinst = [ llinstruction | `CallInst | `CallSite ] type llinvokeinst = [ llinstruction | `InvokeInst | `CallSite ] val does_not_return : [> `CallSite] t -> bool It makes the variant types a little mor...

Erick, After some experimentation, I'd prefer the closed system. LLVM has some type peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in