Bump mixin from 0.7.11-SNAPSHOT to 0.8.2

[dependabot]

Bumps mixin from 0.7.11-SNAPSHOT to 0.8.2.

Release notes

Sourced from mixin's releases.

Mixin 0.8.1

Hotfix for ModLauncher 7.0 support. Also fixes a critical error with resolving methods in inherited interfaces which was breaking many builds.

Mixin 0.8 is something of a milestone so I'd like to take this opportunity to talk about both important changes in this version, and also draw attention to some more subtle changes addressing minor bugs and improving general quality of life for mixin authors.

Version 0.8 brings a lot of internal structural changes to Mixin but a not insignificant part of the update deals with myriad small issues which both make some Mixin features more reliable and consistent (from a mixin author point of view) and also make 0.8 feel more mature by fixing small corner-cases where functionality was either poorly documented or just plain missing. The result is that Mixin 0.8 presents a noticably more refined end-user experience which I hope will be felt by those who work with mixins on a regular basis, but also by newcomers who could often be caught out by some of Mixin's hidden gotchas.

Headline Features

Obviously headline features for 0.8 are support for ASM 6.2 and cpw's excellent new modding platform ModLauncher. Like all Mixin versions, a focus on backwards compatibility has always been paramount, and it's with some reluctance that I've had to introduce a fairly unpleasant departure from that policy in the 0.8: namely the removal of the shaded-and-relocated ASM library in favour of using stock ASM. To be clear, this only has implications for the following elements:

• Mixin config companion plugins which make use of the preApply and postApply callbacks to inspect or make changes to target classes.
• Custom injection points

In the former case, a shim is provided so that any mixins compiled for 0.7 or earlier and using a config companion plugin will continue to work if they do not make any use of the supplied ClassNode (eg. if they use the callback purely for logging or other similar purposes). For the latter case, an error will be reported.

This change was unfortunately necessary since, under the ModLauncher regime, transformers work directly with a ClassNode created by the transformation pipeline rather than with raw byte arrays. Since mixin works extensively with the ASM tree API itself, the only alternative would be to somehow proxy the incoming ClassNode - an unacceptable performance penalty for such a small backwards compatibility benefit.

The practical upshot of all this is that the vast majority of mods running under 1.12.x and using Mixin will continue to work if they upgrade to Mixin 0.8 in-place, or if a newer mod bundling 0.8 is present. Things will only break if a mod compiled for 0.7.x and using either of the features mentioned above is loaded under a Mixin 0.8 library bundled by another mod. As always, I have adhered to the "fail fast" contract, and Mixin will crash early with a descriptive error if this situation arises.

With ASM 6.2 comes the possibility of supporting Java 9 and partial support for Java 10. Though mixin doesn't specifically provide any functionality for those java versions yet, the compatibility levels are now available. But why - I hear you ask - ASM 6.2 when 7.0 and even 7.2 are available? The primary reason is to maintain parity with ModLauncher, since it now exists as the primary target platform for Mixin, compiling under that version makes the most sense for ensuring stability. A secondary reason is that incremental updates make the process of tracking down version-specific bugs slightly easier, since they can be identified and squashed on an ongoing basis.

In order to preserve backwards compatibility with older platforms, Mixin will still run on ASM 5.x and this is achieved by detecting the ASM version at startup and gating unsupported functionality based on the detected version. This mechanism also provides a means for supporting future versions, so expect to see ASM 7.x support arrive in the not-too-distant future.

Toolchain and Environment Changes

Mixin 0.8 adds support for ForgeGradle 3.0 used for Minecraft 1.13 and 1.14 modding, specifically adding support for the new TSRG mappings format. The old services are still available to maintain backwards compatibility with 1.12 and earlier. However note that for MixinGradle, the companion gradle plugin which makes using the mixin AP much easier, you need to update to MixinGradle 0.7 in order to support ForgeGradle 3.0 and the new mappings type.

Since CoreMods have changed significantly in Forge, Mixin now provides a new bootstrapping mechanism in the form of Mixin Connectors. Mixin Connectors replace the functionality which would have previously been the duty of your CoreMod class, with the exception of initialising mixin itself. Migrating CoreMod code to Mixin Connector for 1.14 requires 2 steps:

• Create a class which implements IMixinConnector and place your initialisation code sans the call to MixinBootstrap.init() in the connect() method.
• Specify the name of your IMixinConnector class as the value for the MixinConnector key in your manifest

Notable Bug Fixes

If you're a long-time user of Mixin, then the more interesting changes are likely to be those with a smaller footprint but which nevertheless address some irritations, minor bugs and omissions with Mixin. Notable changes are as follows:

• Static accessor methods now work properly Previously a static @Accessor method in an interface would function only if the class loading order was such that the target class was loaded first. Static accessors now work correctly regardless of the class loading order

• @Invoker can now be used to invoke private constructors It's my life mission to make Access Transformers redundant and a new feature in Mixin 0.8 is the ability to create an @Invoker method which acts as a factory, invoking an inaccessible constructor.

• Accessor mixins now work properly inside other mixins A small bug with a big impact. Accessor Mixins now work properly when used inside another mixin's code, previously attempting to do this would yield a slightly cryptic error about not finding the accessor mixin in the target's hierarchy.

• Mixin application continues if an optional mixin fails Previously any mixin failing during preprocessing or application would lead the mixin applicator shutting down, with optional mixins generating a warning and required mixins raising an exception. From 0.8, failures in optional mixins are collected and reported, but other mixins for the same target will still be applied. The behaviour for required mixins remains unchanged.

• More reliable local variable capture in @Inject

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #36.