Harmony 3.0: Utility Epic

[Aragas]

• Add nullable support
• New logging system
• Backports from https://github.com/BUTR/Harmony.Extensions:
  • Overrides for AccessTools, SymbolExtensions
  • Take a look at the delegate compiler and whether it's better/faster
• Investigate if the Utility classes can be separated from Harmony
• Implement Deprecate transpiler ILGenerator parameter in favor of some Label/LocalBuilder factory #317

[Banane9]

Would offer some help in terms of discussing ideas, design and implementations too, where needed / possible 👀

[pardeike]

You are welcome to discuss architectural design and decisions regarding switching method building completely to CodeInstruction as a first pass. I am in the middle of that and have a non-functional branch I could push.
It's a big fricking rewrite that currently makes tests fail but I have not found a better way to do it.
Thereafter could be a way to get rid of all Reflection.Emit dependencies but that's a different topic.

[Banane9]

There's a lot of abstractions in general that I think could help to make following the internal logic easier - although I recognize that the "down to the metal" nature of some of the things harmony does and the hackiness that necessitates aren't perfectly suited for that.

I also agree with the point on separating the Utility classes (Access Tools, Traverse... anything else?) - They seem like they'd be perfectly suited for a sort of more general reflection library, rather than just being something that comes with the "hacky" patching that is the core of this library 🤔

[pardeike]

Agreed on moving non-essentials out of Harmony into HarmonyTools.

[gotmachine]

Regarding #317, I'd like to point that Harmony is currently missing a way to remove existing labels and locals in a transpiler.

I'm currently achieving it with some ugly hacking taking advantage of the fact that Harmony is "leaking" its ILGenerator, which allow me to access the underlying CecilILGenerator.

It would be nice if the new proposed abstraction for labels and locals also expose the existing ones along with a way to edit/remove them.

[pardeike]

@gotmachine What is the use case you have in mind? In other words, what are the downsides of not being able to remove local variables and variables? You can remove labels from code.Labels and from the operand of jump instructions, so that’s possible. Original local variables can be left unused and won’t affect the generation of the replacement method.

[gotmachine]

The use case is for being able to entirely swap the original IL with what I'm getting from another method (using PatchProcessor.GetOriginalInstructions()), with a few IL modifications I'm doing dynamically.
Having the original labels/locals in the way force me to mangle with the indices for all labels and stloc/ldloc instructions, not a huge issue but it would be nice to have the ability to define a transpiler from a blank state.

[pardeike]

I see. This will be easier if we replace all types related to Reflection.Emit with internal representations. This will then make it easy to reuse [CodeInstruction] except that if your methods have different signatures the references to parameters or return types might need adjusting. The master branch right now has a functional refactor to express all build logic with pure CodeInstruction and in the #contributor channel on the official discord are ongoing discussions on breaking backwards compatibility (like editing the public API of CodeInstruction