search for: llinstruction

...oesNotReturn. 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 more complicated, but end users wouldn't work directly with the variants so there might not be that much added compl...

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