Improvements to struct interop for DOTS

[limoka]

This PR includes three improvements, which make working with DOTS based games much easier:

• Allow to inject custom structs into il2cpp runtime.
• A fix to how methods with struct pointers are generated.
• Allow Generic structs to be marked as blittable. This change could be breaking as some structs previously marked as classes now are structs. I'm performing checks if the struct is indeed blittable and making it's generic parameters constrained to unmanaged.

[limoka]

With the last commit, I think I fixed the generation issue Kasuromi found earlier. Now I added another kind of TypeSpecifics: GenericBlittableStruct, meaning blittability depends on used type arguments. For such structs I generate both boxed and unboxed versions, and switch them depending on the generic arguments.

[ds5678]

Hello! I am open to reviewing this pull request if you rebase it.

[limoka]

I can do that sometime later, however recently I'm rather busy with Core Keeper's 1.0 release.
On top of that I no longer have a test game. Core Keeper no longer uses il2cpp, and the only other game I know of that uses this PR is VRising.

[limoka]

Also if I had to guess there is a lot of changes that would be needed because of #124 for this to work properly.

[ds5678]

Also if I had to guess there is a lot of changes that would be needed because of #124 for this to work properly.

That is correct. The switch to AsmResolver required many changes. In some ways, it was a rewrite of the generator.

[limoka]

Do you have any Cecil to AsmResolver migration guides perhaps? I'm not familiar with the latter.

[ds5678]

They are very similar, though I don't have any guides.

[limoka]

@ds5678 Hello, I have rebased and updated the PR in order to work with AsmResolver as you asked. (Previous version of the PR is available here)

I have checked that the output of this version of PR is consistent or very close to original PR output. To verify this I used your tool mentioned in your #124 PR.
For these checks I have used VRising game, which is one of other known to me il2cpp + DOTS games (Core Keeper has switched to mono, so I'm unable to test on it)
On VRising's ProjectM.dll all 7k types match, only ~3k methods differ from ~55k, only ~3k fields differ from ~54k. Of the differences I found, most are either fixed issues or irrelevant differences.

Additionally I have installed a few mods from VRising Thunderstore (Bloodstone, VCF). From my quick test, all tested mods are working.

[ds5678]

Not injecting all the instance fields of a struct sounds like a bad idea.

[limoka]

Well, you are definitely correct that this is a bad idea.

The reason I did this was that you cannot inject a generic type. And I needed to have my job structs contain a handle type. Like this:

public struct ExampleJob
{
    //These fields can be used as is
    public float inputData;
    public NativeArray<Entity> entities;
    public EntityCommandBuffer ecb;

    // I can't inject this type, nor can I use original type (Because it doesn't have code compiled for CustomComponentCD)
    // So I hide the field
    [HideFromIl2Cpp] 
    public ModComponentDataFromEntity<CustomComponentCD> inputFromEntity;
}

In order not to have crazy issues I had to hack Job Scheduler code, access internal structs and manually adjust the struct size for the code to work.
Or simply it's a giant hack, but it did work. (Here's the code: link)

As such I see two solutions:

1. Remove this ability and implement generic injection or some way to use generic types with types not used by the game code (This one would probably be a huge thing, and would simplify a lot of things I had to do)
2. Keep this for now, but perhaps warn if encountered to inform the modder about consequences of doing this

[ds5678]

Does baseClassPointer.ValueType return true for System.ValueType? If not, this shouldn't be changed.

[limoka]

I'm pretty sure it does return true. This check being removed is exactly why structs can be injected. This is big part of this PR.

Specifically structs are needed because Unity's ECS (Entity Component System) heavily relies on structs to hold game state. By injecting custom ones we can add our own game state.

[ds5678]

What's wrong with AsmResolver.DotNet.Signatures.GenericContext?

[limoka]

The problem is that It handles a different problem. Specifically GenericContext allows to resolve a type from a GenericParamterSignature.
But what I need here is to resolve GenericParameter (Which has all the information about the parameter including constraints and attributes) from GenericParamterSignature (Which is a weird type that doesn't even know who it belongs to).

This is all caused by the weird design of AsmResolver. I have read some messages on their discord describing why GenericParamterSignature is as it is. However the fact metadata stores it this way, doesn't really justify complicating handling of GenericParamterSignature by making them glorified ints. I found Cecil's approach of GenericParameters having all context at all times much more convenient, and the code was written around that.

So GenericParameterContext was needed to implement the logic with AsmResolver. Perhaps maybe Washi can take a look at this code and say how they would do it.