Mumfrey
Mumfrey
> *@kitlith wrote:* However, it means that we have to consider interactions with stuff like `@Shadow` -- is it ever useful? Do we want to keep the non-useful behaviour in...
> * we want it to work on fields I think this makes sense, but part of the discovery you're doing is to determine whether there are any unintended side-effects...
That really just sounds like it's outside the scope of this issue. If people do dumb things that's on them. This is just a tool which conditionally turns things off....
>1. Calling a method that didn't end up getting merged... > 1. via injector: > * Fails at runtime with `NoSuchMethodError`. > 2. via interface: > * Fails at runtime...
This feature will resolve #69
I'll take a look at this on the 17th. This kind of implementatio needs special attention because of the need to handle synthetic bridges.
Just to provide some explanation as to why this is non-trivial. When implementing a generic interface this way, where a type argument appears in a signature of an interface method,...
Added the `annotation processor` tag as well since support for this feature will need to be integrated into the AP.
I swear I tested this... Mixins are supposed to be unmapped in the context of their target so this *should* already be covered. I'll look into it anyway.
Good find, will fix.