Parameter capture fails in Minecraft Classic/Indev/Infdev

[SpaceWalkerRS]

The Proguard settings used for these versions include a local variable optimization that drops locals to lower indices in the stack frame. It even re-uses indices normally reserved for the method parameters. As a result, (some) parameters are no longer accessible from everywhere in the method.

As an example, in Minecraft Infdev 0.31.20100629 there's a method MobEntity.die(Entity)void (Feather mappings). At the start of the method, there are just two locals in the stack frame:

• 0: MobEntity (the this variable)
• 1: Entity (the method parameter)

Early on in the method, a new int variable is created, after which the following locals are in the stack frame:

• 0: MobEntity (the this variable)
• 1: int (the new variable)

The method parameter has completely disappeared, and is no longer accessible from this point on. This causes crashes when injectors target any instruction after this point, and try to access the method parameter. Mixin assumes the parameter is available at index 1, and attempts to pass the int variable where an Entity variable is expected, leading to a VerifyError.

I am not sure if it is within scope for Mixin to fix this, but I thought it would be good to have it documented regardless.

[cputnam-a11y]

Theoretically mixin could just shift new locals after the parameter slots, and adjust the frames accordingly, correct?

[Chocohead]

You should already be able work around this with Mixin Extras. Just don't take any parameters in your @Inject and instead capture them as @Locals, stuffing them in a @Share to prolong their life if necessary.

I did something along those lines 5 years ago with TextileMC for Infdev 20100618:

• The mixin accessing the parameters explicitly by LVT slot
• The Mixin plugin doing the heavy lifting to make that work

This was long before Mixin Extras was conceived, hence the slightly different approach, but it was the same problem acting as motivation. Using Mixin Extras the first handler would be something like...

private void onBlockRender(CallbackInfoReturnable<Boolean> call, @Local Block block, @Local(ordinal=0) int x, @Local(ordinal=1) int y, @Local(ordinal=2) int z) {

Shifting all the locals around to make room for the unchanged parameters is really a hack around Mixin not letting you extend an arbitrary local's life beyond its last use. Mixin can already extend the life of locals in a scope through its zombie system, but this is just for a given slot so won't work after the slot is re-used.
It would be syntaxically possible to achieve life extension in a more compact way than needing two handlers (one catching the value before it's replaced then the other using it) by specifying the point a @Local should be captured from. Whether you'd want to encourage people to do that by making it easier (and more magic) is another matter.

[SpaceWalkerRS]

I suppose that's another work-around. Ideally, though, there'd be a way for Mixin to work like normal. If this is not within scope for Mixin to fix, then I'm gonna consider patching the jar before launch to ensure the expected behavior from Mixin.