[GROOVY-10544] Static compiler chooses superinterface return type

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Resolved
• Affects Version/s: 4.0.1
• Fix Version/s: 4.0.2
• Component/s: Static compilation, Static Type Checker
• Assignee: Eric Milles
• Reporter: Christopher Smith
• Created: 24/Mar/22 17:36
• Updated: 29/Apr/22 20:44
• Resolved: 13/Apr/22 20:36

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:

List<DeleteItemRequest> batch = createBatch() // from Amazon DynamoDB SDK 2
Map<String, List<DeleteItemRequest>> requestsByTable = 
  batch.stream().collect(toMap(DeleteItemRequest::tableName, List::of))

This results in the error

Groovy:Failed to find the expected method[tableName(java.lang.Object)] in the type[software.amazon.awssdk.services.dynamodb.model.DeleteItemRequest]

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.

Issue Links

• is duplicated by: GROOVY-10613 Fail to infer correct types for fluent method calls
• is related to: GROOVY-10054 STC: Cannot infer lambda parameter types for a stream collector