Closed quat1024 closed 2 years ago
unrelated, but according to the jvm spec part about field resolution it should recursively check superclasses of Superclass
for a field named field_176387_N
, and in production that field exists, so i dunno why this crashes at all! (still, if the fields actually held different values, it would behave differently than it does in dev)
This would better be brought up on the repo of the tool that is used to remap mods. https://github.com/md-5/SpecialSource Weird case, but should be simple enough to do a find first.
Probably would be fixed by moving to FART. For now, this is not us. Issue is still open on SpecialSource's repo.
A full compileable test case is at https://github.com/quat1024/bugtest if you want to try it
FG version "5.1.+" but I can also reproduce it on "3.0.+"
Easiest to explain by example, so here's the scene:
The important parts:
Superclass
extends Minecraft'sDirectionalBlock
, and both classes have a field namedFACING
. Mine shadows theirs.DirectionalBlock.FACING
should be remapped toDirectionalBlock.field_176387_N
, but references toSuperclass.FACING
should stay the same.Subclass
refers to that field.After building a reobf jar with the
build
task and examining the output through the IntelliJ decompiler:Superclass
correctly contains two fields namedFACING
andPOWERED
,Superclass#createBlockStateDefinition
correctly refers to the fields namedFACING
andPOWERED
,Subclass#getStateForPlacement
incorrectly refers to fields namedfield_176387_N
andPOWERED
instead.This fails at runtime with a
NoSuchFieldError
, see https://github.com/quat1024/incorporeal-2-forge/issues/11.Only accesses from subclasses are incorrectly remapped. Referring to the public static field
Superclass.FACING
from an unrelated class uses the correct name ofFACING
.