You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Daniel Sun (Jira)" <ji...@apache.org> on 2021/04/19 02:12:00 UTC

[jira] [Resolved] (GROOVY-9800) Log generic mismatches extensively

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

Daniel Sun resolved GROOVY-9800.
--------------------------------
    Fix Version/s: 4.0.0-beta-1
       Resolution: Fixed

The proposed PR has been merged. Thanks!

> Log generic mismatches extensively
> ----------------------------------
>
>                 Key: GROOVY-9800
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9800
>             Project: Groovy
>          Issue Type: Improvement
>          Components: Static Type Checker
>    Affects Versions: 3.0.6
>            Reporter: Christopher Smith
>            Assignee: Eric Milles
>            Priority: Minor
>             Fix For: 4.0.0-beta-1
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently, when the static type checker detects a mismatch in generic bounds, it outputs a message of the form
> {code}
> Groovy:[Static type checking] - Cannot call <D> io.vavr.control.Either <com.example.JsonApiErrorResponse, com.example.JsonApiDataResponse>#toResponseEntity() with arguments []
> {code}
> In this case, both {{JsonApiErrorResponse}} and {{JsonApiDataResponse}} are generic types themselves. It would be helpful for debugging (either identifying STC problems or realizing where my own errors are) if the error message output the actual bounds involved. As it is, it's unclear exactly what the STC doesn't like about my pipeline, and in some of these cases it appears that it may be having trouble solving nested generics.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)