runtime: Ordering unimplemented ILVerify errors by their impact in compiler output validation

This is very subjective. Most unimplemented errors between UnknownOpcode and ThisMismatch in https://github.com/dotnet/corert/blob/master/src/ILVerify/src/VerifierError.cs are interesting.

My approach here is to prioritize the errors by the chances of seeing such violation without triggering some internal asserts in our compilers. Basically - bugs at higher levels of abstraction typically result in logically incorrect and yet valid IL, so IL verification cannot help there. However bugs at lower levels often result in malformed IL and that is where IL verification could be very helpful.

I would start with completing errors related to control flow, stack misbalances and uninitialized data. If IL is malformed due to a bug, it often ends up triggering these. Many look already implemented, but there are still some not yet done.

• //E_BAD_JMP_TARGET “jmp / exception into the middle of an instruction.”
• //E_BR_OUTOF_FIN “Branch out of finally block.”
• //E_BR_TO_EXCEPTION “branch/leave to the beginning of a catch/filter handler”
• //E_FALLTHRU_EXCEP “fallthru the end of an exception block.”
• //E_FALLTHRU_INTO_HND “fallthru into an exception handler.”
• //E_FALLTHRU_INTO_FIL “fallthru into an exception filter.”
• //E_LEAVE “Leave from outside a try or catch block.”
• //E_BACKWARD_BRANCH “Stack height at all points must be determinable in a single forward scan of IL.”
• //E_THIS_UNINIT_BR “Branch back when this is uninitialized.”

Then there are bugs where something went wrong with dataflow or casts. In such cases we generally see various stack corruptions and mishaps with type compatibility.

• //StackNotEq, // Non-compatible types on the stack.

The shape of exception handling regions could be delicate, but the area is not currently in active development so these can be done later.

• //E_TRY_GTEQ_END “try start >= try end.”
• //E_TRYEND_GT_CS “try end > code size.”
• //E_HND_GTEQ_END “handler start >= handler end.”
• //E_HNDEND_GT_CS “handler end > code size.”
• //E_TRY_START “Try starts in the middle of an instruction.”
• //E_HND_START “Handler starts in the middle of an instruction.”
• //E_TRY_OVERLAP “Try block overlap with another block.”
• //E_TRY_EQ_HND_FIL “Try and filter/handler blocks are equivalent.”
• //E_TRY_SHARE_FIN_FAL “Shared try has finally or fault handler.”
• //E_HND_OVERLAP “Handler block overlaps with another block.”
• //E_HND_EQ “Handler block is the same as another block.”
• //E_FIL_OVERLAP “Filter block overlaps with another block.”
• //E_FIL_EQ “Filter block is the same as another block.”
• //E_FIL_CONT_TRY “Filter contains try.”
• //E_FIL_CONT_HND “Filter contains handler.”
• //E_FIL_CONT_FIL “Nested filters.”
• //E_FIL_GTEQ_CS “filter >= code size.”
• //E_FIL_START “Filter starts in the middle of an instruction.”
• //E_ENDFILTER_MISSING “Missing Endfilter.”