NeoForge Merges Mojmap Methods Causing Intermediary Mapping Conflicts

[Kneelawk]

The Issue

Because NeoForge uses mojmap everywhere, they can take two methods in different classes that have the same signature and have both classes implement a new interface that unifies those two methods. However, this breaks in arch-loom because arch-loom needs to map everything to intermediary in order to map to the destination mapping. And in intermediary, because these methods were completely unrelated, they have different signatures.

Example

In this case, ClientCommonPacketListenerImpl and ServerCommonPacketListenerImpl both have a method send(Lnet/minecraft/network/protocol/Packet;)V. NeoForge adds an interface called ICommonPacketListener and has these two classes implement it. ICommonPacketListener also has a method send(Lnet/minecraft/network/protocol/Packet;)V, thus unifying these two methods.

However in intermediary, ClientCommonPacketListenerImpl.send is net.minecraft.class_8673.method_52787 and ServerCommonPacketListenerImpl.send is net.minecraft.class_8609.method_14364, meaning that these two methods have different and incompatible signatures.

How to Reproduce

This issue currently affects Neoforge PR #835. Simply using this version of neoforge in an architectury-loom project will produce mapping conflicts.

Error Log

I have uploaded a copy of the gradle output to patebin.

Environment Details

• Architectury Loom: 1.6.394
• NeoForge: 20.5.0-alpha.1.20.5-rc1.20240422.033338
• Java: openjdk 21.0.2 2024-01-16 LTS
• OS: Linux

[Jab125]

A possible workaround is loom is to create bridge methods

[Kneelawk]

I'm attaching the stack trace as well: https://pastebin.com/1A12RgbG

[Jab125]

NeoForge#835 has been merged in NeoForge 20.6.3-beta