denwav / hypo Goto Github PK

Synthetic methods can be generated on subclasses, but then point to a method on the superclass. The invoke instruction used is the INVOKESPECIAL which currently the BridgeMethodHydrator treats as invalid, and so the method isn't hydrated properly.

There is also a check to make sure the class names are the same which isn't required.

And this also will probably requiring changing the HypoHydration.SYNTHETIC_SOURCE to be able to hold multiple methods, as there can be more than 1 synthetic bridge pointing to the same method.

AsmMethodData is used as the target type for LambdaCallHydrator and LocalClassHydrator which excludes constructors from being hydrated.

When checking if a hydration provider applies to an impl of ClassData, FieldData, or MethodData, the check is reversed where it currently checks if the target class supplied by the HydrationProvider extends the method's actual class.

It should instead of the method's actual class extends the target class from the HydrationProvider.

In determining captured values in the LocalClassHydrator, it assumes an incorrect order of fields, breaking out a loop to collect fields before all captured values have been collected.

class Demo {

	Demo(String arg1, String arg2) {
		
		class Other {
			private final String innerValue = "test";

			public String toString() {
				return arg2 + this.innerValue;
			}
		}

		new Other().toString();
	}
}

The above example produces a list of fields that begins with the "innerValue" field, then the 1 val$arg2 field, then the this$0 field.

The LambdaCallHydrator doesn't properly capture param lvt indicies if one of the parameters comes from a field node. Now usually this isn't the case, but it seems to be in the following situation.

abstract class AbstractClass {
	abstract Supplier<String> get(String arg);
}

class OuterClass {
	
	AbstractClass create(final String input) {
		final String value = input + "other";
		return new AbstractClass() {
			@Override
			Supplier<String> get(String arg) {
				return () -> value + arg;
			}
		}
	}
}

In this example, the lambda at OuterClass$1$lambda$create$0 (I think that's the correct name it'd have) or the one on being returned from the overriden method won't have the "arg" param marked as captured.

The issue comes from the logic collecting the param indicies. If it encounters a non var insn it breaks out of the loop, not completing the collection so an empty array is set in the LambdaCall object.

The CopyMappingsDown mappings change contributor doesn't check to make sure the parameter for which it is applying mappings would actually have a mapping.

class ParentClass {
	static class InnerStaticClass {
		InnerStaticClass(ParentClass parent, double value) {
		}
	}
}

class ChildClass extends ParentClass {
	class InnerClass extends ParentClass.InnerStaticClass {
		InnerClass(double value) {
			super(ChildClass.this, value);
		}
	}
}

The above example, if provided with mappings only for ParentClass$InnerStaticClass#<init> would apply 2 parameter mappings to ChildClass$InnerClass#<init>, the double param's mappings as well as the implicit ParentClass parameter.

I assume this is also an issue for any captured variables that would be in the constructor of a method-local class.

Tests I wrote to demo the issue: https://pastes.dev/BMugODf0zE

Method local records and enum are "static", in that even in non-static parent methods, they cannot access state from the enclosing class. The method on ClassData incorrectly reports them as not static inner classes.

Also, method local classes inside static methods are also static are incorrectly reported as not static classes.