Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge from upstream (Mixin 0.8.7) #3

Closed
wants to merge 118 commits into from

Conversation

Rongmario
Copy link
Member

No description provided.

Mumfrey and others added 30 commits December 1, 2021 20:50
Fixes remapping of synthetic members in resolvable classes.

(cherry picked from commit c33a48b)
Extending an already-compiled mixin no longer results in an error, and extending (a mixin that targets) your target class does result in an error.

(cherry picked from commit 7f7dbc1)
We no longer use mirror. The generics are irrelevant in the first place because Mixin does not check them at runtime.

(cherry picked from commit ccfb5ee)
…onment rather than on the Package specification version, since that version is unavailable in two scenarios: 1) ML loaded as a JPMS module and 2) ML added to the classpath using a folder rather than JAR-file.
* Include the Gson module deps in the module-info

* Fully fix modularity

* Update PatternCompiler.java
* Fix: Resolve `@Redirect`s breaking `@ModifyArg`.

* Fix: Resolve `@Redirect`s breaking `@ModifyArgs`.
The old logic misses the receiver and does not correctly handle double-size types.
@Rongmario Rongmario marked this pull request as draft July 18, 2024 09:42
Bafflingly, Mixin fails to match a `NEW` instruction whose `<init>` call is outside the slice range, *iff the user specified a descriptor*.
I'm even more surprised that a mod relied on this.
Fixes FabricMC#152.
…sers.

These will never match because the LHS is the mixin name and the RHS is the target name.
This restores the 0.8.5 behaviour which does not check the owner at all.
We have never supported assignment expressions in initialisers until now anyway, and even if we check the owner we cannot determine whether the instruction is operating on the current *instance* without proper static analysis, so IMO there's not much point bothering.
modmuss50 and others added 9 commits August 13, 2024 08:40
The old one did not properly account for discontinuities in the list, leading to double-width types clobbering meaningful locals and causing mysterious VerifyErrors.
`InjectionInfo.parse` can be very expensive and in the case of some MixinExtras features is not pure.
The correct approach would be to use `InjectionInfo.getInjectorAnnotation`, but the override is no longer needed anyway since we only support Java 8+ so Mixin will already make injector methods private and synthetic.
Except, Mixin does it based on the current `COMPATIBILITY_LEVEL`, which is wrong, because we could be on JAVA_17 and yet a class compiled with JAVA_8 had no choice but to use public methods.
The original implementation was also incomplete because it forgot about default methods.
@Rongmario Rongmario closed this Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants