在使用自家 XDecompiler 反向 1.14.4 版本时，在以 mojmaps 为目标映射反混淆时出现如下错误：Mapping source name conflicts detected:
ase METHOD w ((I)V) -> [ase/setDespawnDelay, ase/setStrength]
(...)
Caused by: java.lang.RuntimeException: Unfixable conflicts
at net.fabricmc.tinyremapper.TinyRemapper.handleConflicts(TinyRemapper.java:867)
排除其他映射表的影响后（只留下 official -> [mojmaps]），发现问题依旧存在。
于是我打开官方映射表（client.txt）：net.minecraft.world.entity.animal.horse.Llama -> ase:
(...)
80:81:void setStrength(int) -> wnet.minecraft.world.entity.animal.horse.TraderLlama -> asi:
(...)
65:66:void setDespawnDelay(int) -> w
可以看到，ase.w(I)V 和 asi.w(I)V 的“混淆后”方法签名完全相同，但“混淆前”方法签名不同。
XDecompiler 调用 TinyRemapper 时，会打开 resolveMissing 选项，没完全看懂源码但是大致推测该选项会在 子类没有 target name 的情况下使用父类的 target name。
对client.jar的 ase 和 asi 类进行一个javap 后，发现 asi 是 ase 的子类，并发现 ase有 w 方法：private void w(int);复制代码
然而对 javap -p -cp client-1.14.4.jar asi 的输出结果进行一个 grep 'w('，结果发现 asi 并没有覆写 w 方法，映射表里的 setDespawnDelay 方法根本不存在。
我不知道为什么会出现这种情况——是不是BUGJUMP在执行ProGuard的时候把这个方法给shrink掉了
以及 fabric-loom 在相同版本下使用 loom.officialMappings 会不会出现同样的报错——毕竟读取 Mapping-IO 的 MappingTreeView 用于 Tiny-Remapper 这部分的代码是我从loom抄的，而 Mapping-IO 自带 ProGuardReader 可以读取 mojmaps（我的 XDecompiler 和 loom 用的都是这个）
以及如何解决这个冲突。我不希望手改 mapping，因为临近的几个版本都有这个问题，而我需要自动化地反向若干版本。
ase METHOD w ((I)V) -> [ase/setDespawnDelay, ase/setStrength]
(...)
Caused by: java.lang.RuntimeException: Unfixable conflicts
at net.fabricmc.tinyremapper.TinyRemapper.handleConflicts(TinyRemapper.java:867)
排除其他映射表的影响后（只留下 official -> [mojmaps]），发现问题依旧存在。
于是我打开官方映射表（client.txt）：net.minecraft.world.entity.animal.horse.Llama -> ase:
(...)
80:81:void setStrength(int) -> wnet.minecraft.world.entity.animal.horse.TraderLlama -> asi:
(...)
65:66:void setDespawnDelay(int) -> w
可以看到，ase.w(I)V 和 asi.w(I)V 的“混淆后”方法签名完全相同，但“混淆前”方法签名不同。
XDecompiler 调用 TinyRemapper 时，会打开 resolveMissing 选项，没完全看懂源码但是大致推测该选项会在 子类没有 target name 的情况下使用父类的 target name。
对client.jar的 ase 和 asi 类进行一个javap 后，发现 asi 是 ase 的子类，并发现 ase有 w 方法：private void w(int);复制代码
然而对 javap -p -cp client-1.14.4.jar asi 的输出结果进行一个 grep 'w('，结果发现 asi 并没有覆写 w 方法，映射表里的 setDespawnDelay 方法根本不存在。
我不知道为什么会出现这种情况——是不是BUGJUMP在执行ProGuard的时候把这个方法给shrink掉了
以及 fabric-loom 在相同版本下使用 loom.officialMappings 会不会出现同样的报错——毕竟读取 Mapping-IO 的 MappingTreeView 用于 Tiny-Remapper 这部分的代码是我从loom抄的，而 Mapping-IO 自带 ProGuardReader 可以读取 mojmaps（我的 XDecompiler 和 loom 用的都是这个）
以及如何解决这个冲突。我不希望手改 mapping，因为临近的几个版本都有这个问题，而我需要自动化地反向若干版本。