[
https://issues.apache.org/jira/browse/GROOVY-10544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Smith updated GROOVY-10544:
---------------------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
>
> 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)
