[jira] [Resolved] (GROOVY-10544) Static compiler chooses superinterface return type

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

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

Eric Milles resolved GROOVY-10544.
----------------------------------
    Resolution: Resolved

> Static compiler chooses superinterface return type
> --------------------------------------------------
>
>                 Key: GROOVY-10544
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10544
>             Project: Groovy
>          Issue Type: Bug
>          Components: Static compilation, Static Type Checker
>    Affects Versions: 4.0.1
>            Reporter: Christopher Smith
>            Assignee: Eric Milles
>            Priority: Major
>         Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> I am using Vavr 0.10, which has the following type relationship:
> {{Try<T> extends Value<T>}}
> {{Value}} defines the method {{<U> Value<U> map(Function<? super T, ? extends U> mapper)}}, which is narrowed in the interface definition for {{Try}} to return a {{Try<U>}}. When used in a functional pipeline, however, the STC infers {{Value<U>}} as the return type even when it knows that the previous value is a {{Try<T>}}, causing downstream type failures. Instead, it should infer that the return type is the more specific {{Try<U>}}.
> I am inspecting this intermediate inference in Groovy-Eclipse, but the CLI errors I'm getting are exactly consistent with the erroneous inference. I will try to create a minimal replication after getting the ticket ID.
> ---
> This feels like the same problem:
> {code}
> List<DeleteItemRequest> batch = createBatch() // from Amazon DynamoDB SDK 2
> Map<String, List<DeleteItemRequest>> requestsByTable = 
>   batch.stream().collect(toMap(DeleteItemRequest::tableName, List::of))
> {code}
> This results in the error 
> {code}
> Groovy:Failed to find the expected method[tableName(java.lang.Object)] in the type[software.amazon.awssdk.services.dynamodb.model.DeleteItemRequest]
> {code}
> even though from the context it's clear that the type being submitted is {{DeleteItemRequest}}, and Groovy-Eclipse correctly identifies {{Stream<DeleteItemRequest>}}. Somehow the "inner generics context" of {{toMap}} isn't getting the information, which also accounts for the functional-pipeline glitch.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)