Synthetic bridges methods, most commonly seen from implementing generic supertypes, are not logically mapped to be deobfuscated. Taking azb$a => class_1867$class_1868 => ShapelessRecipe$Serializer (which extendsayy => class_1862 => RecipeSerializer) as an example:

• We start with explicit bridge a(Lit;Layw;)V for a(Lit;Lazb;)V
• Intermediary skips mapping the bridge (as it overrides class_1862#method_8124) and maps the actual method to method_8143
• Mapping method_8124 (as Yarn does) carries over to the mapping (here)
• The actual method remains unmapped and is left as method_8143

This process is masked from decompiling hiding bridge methods by default, but the same effect is visibly present from other methods:

• We start with implicit (ie only synthetic) bridge b(Lqc;Lit;)Layw; for a(Lqc;Lit;)Lazb;
• Intermediary skips mapping the bridge (method_8122) and maps the actual method to method_8141
• As before the naming is carried forward
• The actual method remains unmapped, resulting in a mapped read bouncing to an unmapped method_8141

Practically speaking as it stands nothing appears to break from this (after all, Mojang uses different names of a and b), but hiding the synthetic methods as decompilers often do results in classes appearing to not consistently implement interfaces.
This also leaves the door open for the implementing method name to differ from the interface it is implementing, purely as they have different Intermediary names and nothing forces them to be the same. Enigma will happily let you do this as to it they are different methods. Whilst again this isn't technically wrong from the JVM's point of view, you could never write Java code that would naturally compile like that (as well as the decompile having no chance of recompiling).

If the actual methods that are bridged to shared the same Intermediary name as the bridges (and thus the original interface) this would go away as the whole system would change together. Doesn't fix Yarn's problems from mapping to Notch directly, but that is arguably an Enigma problem.

Since 19w37a, PassiveEntity has a new subclass for entity data. However, its intermediary name is that for an anonymous class (net/minecraft/class_1296$1), causing some troubles in procyon and yarn. Not yet sure if this affects mods using passive entity data.

To fix this, just assign a new intermediary name to net/minecraft/class_1296$1 like net/minecraft/class_1296$class_4987 (dunno what the latest id is)

Back in 1.14.4, this TextureUtil class was not obfuscated. Now, it is obfuscated and becomes cvy.

For some reason, this class lacks an intermediary name. In the built yarn tiny file, its intermediary name is just com/mojang/blaze3d/platform/TextureUtil, same as its yarn name.

This issue is urgent: since it has a package-level access (calls net/minecraft/client/texture/NativeImage$GLFormat.getGlConstant()I which is package-private, or cvu$b.a()I), this causes illegal access exceptions when running intermediary-named fabric client for 19w34a.

Example crash report: https://gist.github.com/def790af56fe52fa66fb5941617bbcc4

There are a few entries in the mappings for 1.14.4.tiny that have the intermediary name as the official name. I searched through the list of methods and their signatures to correct the first 7, but the last two entries have the same signature so unsure.

I have not taken a look through the other mappings so these issues might exist within multiple files.

METHOD  cvp$a   ()Lcvp; method_21055    method_21055    doConnect
Fixed (method_21055 -> e)
METHOD  cvp$b   ()Lcvp; method_21055    method_21055    doConnect
Fixed (method_21055 -> e)
METHOD  cvp$c   ()Lcvp; method_21055    method_21055    doConnect
Fixed (method_21055 -> e)
METHOD  cvp$d   ()Lcvp; method_21055    method_21055    doConnect
Fixed (method_21055 -> e)
METHOD  cwg     (ILcwa$a;ZZ)V   method_21108    method_21108    onSlotClick
Fixed (method_21108 -> a)
METHOD  cwg     (Ljava/lang/Object;)V   method_21395    method_21395    callback
Fixed (method_21395 -> a)
METHOD  cwu     (Ljava/lang/Object;)V   method_21395    method_21395    callback
Fixed (method_21395 -> a)
METHOD  cxh$d   ()V     method_21068    method_21068    tick
METHOD  cxh$d   ()V     method_21071    method_21071    abortTask

The remapped game jar has had a class remapped to 1.class ever since 19w12b which was presumed to be an anonymous class at the time in Discord IIRC. Turns out it is not anonymous at all but is in fact OptionButtonWidget. Taking a look one step at a time:

In the 1.14 Yarn mappings cwz is mapped to produce 1.class:

CLASS	cwz	net/minecraft/client/gui/widget/OptionButtonWidget	net/minecraft/1
FIELD	cwz	Lcvl;	a	field_18970	field_18970

As per the 1.14 Intermediaries on lines 23725-6

CLASS	cwz	net/minecraft/1
FIELD	cwz	Lcvl;	a	field_18970

Going back in time to track field_18970, the first reference to it was 19w12b (on lines 23327-8)

CLASS	cvp	net/minecraft/1
FIELD	cvp	Lcud;	a	field_18970

Conveniently the field is 10 before the field counter limit. Looking back to 19w12a however (on lines 23328-9) reveals it never should have been assigned a number that late:

CLASS	cvp	net/minecraft/class_349
FIELD	cvp	Lcud;	a	field_2141

Tracking class_349 back reveals it has existed since the earliest Intermediary release of 18w43b (on lines 4453-5):

CLASS	ckw	net/minecraft/class_349
FIELD	ckw	Lcjm$a;	o	field_2141
METHOD	ckw	()Lcjm$a;	c	method_1899

Thus all along it was an incorrect remapping in 19w12b that both lost the old mapping, and produced the broken naming that has persisted ever since.

As a Fabric modder, I am curious about how the intermediary mapping is produced.

1. Is it auto-generated or artificially uploaded?
2. What's the basis of the generation?

• MojMaps?
• Or something like AI that can compare classes in JARs between versions?

Thank you.

We have seen situations where mojang suddenly deobfuscates existing fields/methods, breaking our mod usage. This has defeated the intermediary names' purpose, i.e. to allow mods to work across versions more easily. Also, see #9; mojang has changed obfuscation status of classes as well, making such intermediary inclusion more necessary.

This repo is getting quite large, and is taking 90+ seconds to checkout on github actions.

One possible solution is to use https://docs.github.com/en/rest/reference/repos#get-a-commit to get the files changed in the commit and just wget/curl the new mapping file. (Re-release can still just take the version)

Putting this idea in writing for safe keeping as I will most likely wait untill after 1.18 has been released to work on this.

As of FabricMC/yarn@4ee3e57, GlStateManager.DestFactor and GlStateManager.SourceFactor use their original names. However, intermediary still has them mapped to class_* variants, which means they must be referred to using those instead:

CLASS    com/mojang/blaze3d/platform/GlStateManager$DestFactor    com/mojang/blaze3d/platform/GlStateManager$class_1027
CLASS    com/mojang/blaze3d/platform/GlStateManager$SourceFactor    com/mojang/blaze3d/platform/GlStateManager$class_1033

(from mappings/19w03b.tiny)

I'm not sure if it'd be better to manually update the tiny files, or re-add the mappings to yarn.

Hey there, not sure if this is the right repository to report this to.
We're having issues mixing into a method present on both the client and server, which on the client implements a method in an interface which is marked as @Environment(EnvType.CLIENT).
Specifically, the method we're trying to mix into is net.minecraft.server.world.ServerChunkManager#tick(java.util.function.BooleanSupplier), which is NOT marked @Environment(EnvType.CLIENT). However, the method it implements, net.minecraft.world.chunk.ChunkManager#tick IS marked with that annotation.
This is leading to the release version of our mod crashing on the dedicated server.

7d8b548