wolvereness / overmapped Goto Github PK

View Code? Open in Web Editor NEW

19.0 19.0 10.0 312 KB

OverMapped - inclusive Java remapping tool

License: Other

Java 100.00%

overmapped's People

Contributors

Stargazers

Watchers

Forkers

tomylobo codename-b thinkofname mbax avafloww tom7762 byteflux resslerruntime sathonay brxve

overmapped's Issues

Allow missing description for fields

Method signatures do not consider remapped class names

When a method signature includes class names that were remapped, it will only consider the original class names.

Add warning if mapped method no-longer overrides parent class

If a method map is added for a class, and the method overrides a parent's class, OverMapped should give a warning.

StringIndexOutOfBoundsException when using a field mapping with no space

 members:
   java/package/SomeClass:
     FIELD_NAME: NEW_NAME

Produces this stack trace:

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
    at java.lang.String.substring(String.java:1949)
    at com.wolvereness.overmapped.MembersSubRoutine.parseMapping(MembersSubRoutine.java:418)
    at com.wolvereness.overmapped.MembersSubRoutine.processSingleClassMappings(MembersSubRoutine.java:230)
    at com.wolvereness.overmapped.MembersSubRoutine.invoke(MembersSubRoutine.java:195)
    at com.wolvereness.overmapped.OverMapped.process(OverMapped.java:210)
    ... 22 more

Consolidate the concept of sections

This expands on the concept from #11, but references that the entire structure can be changed, sans regex, to not be divided in sections.

NullPointerException when executing

Caused by: java.lang.NullPointerException
    at org.objectweb.asm.Type.getObjectType(Unknown Source)
    at com.wolvereness.overmapped.asm.ByteClass$3$1.<init>(ByteClass.java:218)
    at com.wolvereness.overmapped.asm.ByteClass$3.visitMethod(ByteClass.java:216)
    at org.objectweb.asm.ClassVisitor.visitMethod(Unknown Source)
    at org.objectweb.asm.commons.RemappingClassAdapter.visitMethod(Unknown Source)
    at org.objectweb.asm.ClassReader.b(Unknown Source)
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at com.wolvereness.overmapped.asm.ByteClass.call(ByteClass.java:186)
    at com.wolvereness.overmapped.asm.ByteClass$2.call(ByteClass.java:171)
    at com.wolvereness.overmapped.asm.ByteClass$2.call(ByteClass.java:168)
    at com.wolvereness.overmapped.lib.ProperProcessor$Task.calculate(MultiProcessor.java:195)
    at com.wolvereness.overmapped.lib.ProperProcessor$Task.handle(MultiProcessor.java:189)
    at com.wolvereness.overmapped.lib.ProperProcessor$1.run(MultiProcessor.java:255)
    at java.lang.Thread.run(Thread.java:679)

Enums do not properly change their internal name

When mapping the fields of an enum, the internal name is not properly changed. This can be fixed using https://github.com/Wolvereness/Renumerated, but it would be more convenient to integrate this feature.

Allow modification of member declaration flags

Methods that have overloaded return types cause avoidable compilation issues, as outlined at https://bukkit.atlassian.net/browse/BUKKIT-4419. If methods are marked as synthetic (the 0x1000) flag, this becomes a non-issue.

OverMapped could include a system for defining new flags for members, thus alleviating this problem.

Constructors are inherited

Constructors are inherited and incorrectly act as valid targets for flag manipulation in subclasses that do not have the signature.

Using regex transformations fails completely

Duplicate null.class entries when used as last line and completely broken state machine for future mappings.

Methods and fields that switch names get improperly mapped

When two fields or methods with similar names should get switched, they don't actually get switched.

Flag syntax to match the syntax for members

Flag syntax should support the short-hand syntaxes that are used on members.

Finding parents fails when method description includes a mapped-class parameter

Allow short-hand listing of member maps

The current format is very verbose for multiple member maps to a single class. An example:

members:
  "org/bukkit/entity/Damageable _INVALID_damage (I)V": damage
  "org/bukkit/entity/Damageable _INVALID_damage (ILorg/bukkit/entity/Entity;)V": damage
  "org/bukkit/entity/Damageable _INVALID_getHealth ()I": getHealth
  "org/bukkit/entity/Damageable _INVALID_setHealth (I)V": setHealth
  "org/bukkit/entity/Damageable _INVALID_getMaxHealth ()I": getMaxHealth
  "org/bukkit/entity/Damageable _INVALID_setMaxHealth (I)V": setMaxHealth
  "org/bukkit/entity/LivingEntity _INVALID_getLastDamage ()I": getLastDamage
  "org/bukkit/entity/LivingEntity _INVALID_setLastDamage (I)V": setLastDamage
  "org/bukkit/event/entity/EntityDamageEvent _INVALID_getDamage ()I": getDamage
  "org/bukkit/event/entity/EntityDamageEvent _INVALID_setDamage (I)V": setDamage
  "org/bukkit/event/vehicle/VehicleDamageEvent _INVALID_getDamage ()I": getDamage
  "org/bukkit/event/vehicle/VehicleDamageEvent _INVALID_setDamage (I)V": setDamage
  "org/bukkit/event/entity/EntityRegainHealthEvent _INVALID_getAmount ()I": getAmount
  "org/bukkit/event/entity/EntityRegainHealthEvent _INVALID_setAmount (I)V": setAmount

This could be improved by using a format like this:

members:
  "org/bukkit/entity/Damageable":
    "_INVALID_damage (I)V": damage
    "_INVALID_damage (ILorg/bukkit/entity/Entity;)V": damage
    "_INVALID_getHealth ()I": getHealth
    "_INVALID_setHealth (I)V": setHealth
    "_INVALID_getMaxHealth ()I": getMaxHealth
    "_INVALID_setMaxHealth (I)V": setMaxHealth
  "org/bukkit/entity/LivingEntity":
    "_INVALID_getLastDamage ()I": getLastDamage
    "_INVALID_setLastDamage (I)V": setLastDamage
  "org/bukkit/event/entity/EntityDamageEvent":
    "_INVALID_getDamage ()I": getDamage
    "_INVALID_setDamage (I)V": setDamage
  "org/bukkit/event/vehicle/VehicleDamageEvent":
    "_INVALID_getDamage ()I": getDamage
    "_INVALID_setDamage (I)V": setDamage
  "org/bukkit/event/entity/EntityRegainHealthEvent":
    "_INVALID_getAmount ()I": getAmount
    "_INVALID_setAmount (I)V": setAmount

Allow fields to be mapped as a sequence of names

When changing a series of fields, name updates are not reflected

When using a series of values, like

members:
  java/package/Class:
    { [someName, f1, f2, f3, f4 ]: someName }:
    - f1
    - f2
    - f3
    - f4
    - newName

Logically, this should change field someName to newName, but OverMapped will consider f1 to be missing.

Private methods are inherited

Private methods are inherited so renaming them incorrectly modifies sub-classes that have a similarly named method.

Output doesn't behave like a state machine

All mappings behave like a state machine (as if previous mappings have been applied). The debug output however, is only in perspective of the original class names and member descriptions.

Flags do not function

Field references to sub-classes are not mapped

When accessing a field of a sub-class, it changes the bytecode reference for that field to use the name of the current class, instead of the field's declaring class. This is valid bytecode, but OverMapped does not correctly change that reference to use a new name in those situations.

members:
  java/package/Class:
    { [f1, 2, f3]: f1}
    - value1
    - value2

Causes:

Caused by: java.util.UnknownFormatConversionException: Conversion = '2'
    at java.util.Formatter.checkText(Formatter.java:2519)
    at java.util.Formatter.parse(Formatter.java:2483)
    at java.util.Formatter.format(Formatter.java:2430)
    at java.util.Formatter.format(Formatter.java:2383)
    at java.lang.String.format(String.java:2781)
    at com.wolvereness.overmapped.SubRoutine.asType(SubRoutine.java:89)
    at com.wolvereness.overmapped.MembersSubRoutine.processSingleClassMappings(MembersSubRoutine.java:326)
    at com.wolvereness.overmapped.MembersSubRoutine.invoke(MembersSubRoutine.java:196)
    at com.wolvereness.overmapped.OverMapped.process(OverMapped.java:213)
    ... 22 more

And:

members:
  java/package/Class:
    { [f1, f2, f3]: f1}
    - 1