CLR栈合并点不同类型托管指针合并的CIL合规性问询

首先明确ECMA-CIL定义的两类约束的适用范围：

• 正确CIL：是CLR能够加载、JIT编译并执行代码的最低准入要求，不满足该要求的代码会在JIT阶段直接抛出InvalidProgramException，完全无法运行。
• 可验证CIL：是在正确CIL基础上追加的强类型安全约束，主要用于低信任/沙箱场景的权限管控；不满足可验证要求但符合正确CIL要求的代码，在全信任运行环境下可以正常执行。

针对核心问题：符合正确CIL要求的场景下，是允许合并不同类型托管指针的，你看到的ILVerify报错属于可验证性校验失败，不属于CIL正确性错误。

两类约束在多前驱基本块的栈状态合并规则上存在明确差异：

1. 正确CIL的合并要求非常宽松：只要求所有前驱路径到达合并点时的栈深度完全一致，栈上对应位置的值拥有相同的运行时存储表示即可。所有托管指针（即&类型）不管指向的具体元素类型是int32、uint32还是其他引用/值类型，在栈上都是等长的原生地址值，满足存储表示一致的要求，JIT在正确性校验阶段不会拦截这类合并逻辑。
2. 可验证CIL的合并要求严格得多：除了栈深度一致，还要求栈上对应位置的类型必须满足类型等价或隐式赋值兼容规则。int32&和uint32&虽然运行时表示完全相同，但在CIL类型系统中属于两个独立的托管指针类型，不存在合法的隐式转换关系，因此触发了你看到的PathStackUnexpected校验错误。

你构造的测试CIL本身完全符合正确CIL要求：

.method public static void Bar (int32& a, uint32& b, bool d) cil managed
{
    .maxstack 8
    IL_0003: ldarg.2
    IL_0004: brfalse.s IL_000b

    IL_0006: ldarg.0
    IL_0009: br.s IL_000d

    IL_000b: ldarg.1

    IL_000d: pop
    IL_000e: ret
}

这段代码在全信任环境下可以被正常JIT执行，不会抛出任何运行时异常——毕竟pop指令只需要栈上存在一个可弹出的值，完全不关心这个值是指向int32还是uint32的托管指针。C#的unsafe上下文编译出的代码里，这类不同类型指针（包括托管指针、非托管指针）合并的场景非常常见，都属于正确但不可验证的CIL范畴。

补充说明ILVerify的校验逻辑：ILVerify默认同时开启正确性和可验证性两类校验，你看到的这个错误是可验证性规则触发的。如果只校验CIL正确性、关闭可验证性检查，这段代码可以顺利通过校验。

内容的提问来源于stack exchange，提问作者Manuel Carrasco