Right now most of IKVM relies on the System.Reflection.Emit.ILGenerator interface, for construction of method bodies and exception blocks. The same API surface is used from IKVM.Reflection.Emit.
However, most usage of ILGenerator passes through CodeEmitter. CodeEmitter is the main type we use for assemblying IL. It then gets written into ILGenerator.
CodeEmitter, however, possesses most of the same capabilities as ILGenerator, but contains significant numbers of work around for stuff in ILGenerator: such as optimization in ILGenerator that rewrite instructions, etc. CodeEmitter is where our optimizations are applied.
IKVM is a pretty IL deep project, and doesn't need to be going through a higher-level API like ILGenerator. CodeEmitter could emit the IL and exception blocks on it's own. With optimizations that we control.
It looks like we can avoid ILGenerator in .NET Framework 4.5 and above now, since SetMethodBody is available on MethodBuilder. And, for dynamic methods/etc, we have DynamicILInfo with methods to set exception block information. CodeEmitter could write to these instead.
We would be in control of the exact IL emitted and it would remove the need for a very complicated component in IKVM.Reflection, and would require less workarounds.
Right now most of IKVM relies on the System.Reflection.Emit.ILGenerator interface, for construction of method bodies and exception blocks. The same API surface is used from IKVM.Reflection.Emit.
However, most usage of ILGenerator passes through CodeEmitter. CodeEmitter is the main type we use for assemblying IL. It then gets written into ILGenerator.
CodeEmitter, however, possesses most of the same capabilities as ILGenerator, but contains significant numbers of work around for stuff in ILGenerator: such as optimization in ILGenerator that rewrite instructions, etc. CodeEmitter is where our optimizations are applied.
IKVM is a pretty IL deep project, and doesn't need to be going through a higher-level API like ILGenerator. CodeEmitter could emit the IL and exception blocks on it's own. With optimizations that we control.
It looks like we can avoid ILGenerator in .NET Framework 4.5 and above now, since SetMethodBody is available on MethodBuilder. And, for dynamic methods/etc, we have DynamicILInfo with methods to set exception block information. CodeEmitter could write to these instead.
We would be in control of the exact IL emitted and it would remove the need for a very complicated component in IKVM.Reflection, and would require less workarounds.
This is what spawned this: https://github.com/dotnet/runtime/issues/97520