[jira] [Issue Comment Deleted] (GROOVY-8815) Inconsistent class file - undefined type parameter for trait implementer

["Eric Milles (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Milles updated GROOVY-8815:
--------------------------------
    Comment: was deleted

(was: This patch fixed part of my issue.  Compilation from source does not produce any unresolved generics placeholder in the class file.  However, I have one edge case that still does.  When {{Events}} from above comes from a binary (ex: {{grails.events.Events}} from grails-events-compat:3.3.2) I can still get inconsistent class file errors.

I think the problem has to do with the warning on {{GenericsUtils.applyGenericsContextToPlaceHolders}}:
{code:java}
    /**
     * Transforms generics types from an old context to a new context using the
     * given spec. This method assumes all generics types will be placeholders.
     * WARNING: The resulting generics types may or may not be placeholders
     * after the transformation.
     *
     * @param genericsSpec the generics context information spec
     * @param oldPlaceHolders the old placeholders
     * @return the new generics types
     */
    public static GenericsType[] applyGenericsContextToPlaceHolders(Map<String, ClassNode> genericsSpec, GenericsType[] oldPlaceHolders) {
{code}

This method is applied in 3 places that I can find.  2 are for traits and 1 is for synthetic bridge methods.  Once the method has completed, if any {{GenericsTypes}} still contain unresolved placeholders -- can be checked by {{GenericsUtils.extractPlaceholders(genericType[i].getType())}} -- the class file will be written with an unresolved placeholder.

{{TraitComposer}} has the following sequence.  Is the intent here to remove any unresolved generics?  That is, should I be trying to fix {{removeNonPlaceHolders}} so that there are no unresolved items left in any of the passed generics?
{code:java}
            GenericsType[] newGt = GenericsUtils.applyGenericsContextToPlaceHolders(genericsSpec, originalMethod.getGenericsTypes());
            newGt = removeNonPlaceHolders(newGt);
            forwarder.setGenericsTypes(newGt);
{code}
)

> Inconsistent class file - undefined type parameter for trait implementer
> ------------------------------------------------------------------------
>
>                 Key: GROOVY-8815
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8815
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.4.15, 2.5.2
>            Reporter: Eric Milles
>            Priority: Major
>
> When compiling the following classes, the Service class ends up with an incomplete type parameter in it. This causes errors for the IDE: "Inconsistent classfile encountered: The undefined type parameter T is referenced from within Service"
> {code}
> import java.util.function.Consumer
> import groovy.transform.CompileStatic
> class Event<T> {
>   Event(String id, T payload) {
>   }
>   Event<T> setReplyTo(Object replyTo) {
>   }
> }
> @CompileStatic
> trait Events {
>   def <E extends Event<?>> Registration<Object, Consumer<E>> on(Class key, Closure consumer) {
>   }
> }
> interface Registration<K, V> {
> }
> class Service implements Events {
> }
> {code}
> javap output for Events shows:
> {code:java}
>   public abstract <E extends Event<?>> Registration<java.lang.Object,java.util.function.Consumer<E>> on(java.lang.Class, groovy.lang.Closure);
> {code}
> javap output for Service shows:
> {code:java}
>   public <E extends Event<T>> Registration<java.lang.Object, java.util.function.Consumer<E>> on(java.lang.Class, groovy.lang.Closure);
>   public <E extends Event<?>> Registration<java.lang.Object, java.util.function.Consumer<E>> Eventstrait$super$on(java.lang.Class, groovy.lang.Closure);
> {code}
> It is this "T" in the trait method that is not defined. I think it should be "?" instead when looking at the original method's and the trait bridge method's type parameters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)