You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Christopher Smith (Jira)" <ji...@apache.org> on 2022/11/16 16:56:00 UTC

[jira] [Created] (GROOVY-10844) STC mis-tracks generics in type hierarchy

Christopher Smith created GROOVY-10844:
------------------------------------------

             Summary: STC mis-tracks generics in type hierarchy
                 Key: GROOVY-10844
                 URL: https://issues.apache.org/jira/browse/GROOVY-10844
             Project: Groovy
          Issue Type: Bug
          Components: Static compilation, Static Type Checker
    Affects Versions: 4.0.6
            Reporter: Christopher Smith


I have a Vavr {{Try}} pipeline of this form:

{code:groovy}
class AttachmentSpec {
  // fields
  Attachment toAttachment(Ref ref) { ... }
}


Try.success(initialValue)
  .mapTry { process(it) } // returns a Map
  .map { convertToRef(it) } // returns a Ref.File extends Ref
  .recover { new Ref.Uri(it.href) } // Ref.Uri extends Ref
  .map(spec::toAttachment)
{code}

On a failure in {{process}}, this pipeline should enter {{recover}} and supply a {{Ref.Uri}}, then do the final {{map}}. However, this fails with a {{ClassCastException: cannot convert Ref.Uri to Ref.File}}. Apparently, the compiler infers {{Ref.Uri}} as the return value from the first {{map}} (which is legitimate), but then it fails to produce a compile-time error when {{recover}} presents a then-incompatible {{Ref.File}}. The compiler should either (ideally) recognize that the desired type is superclass {{Ref}} or, more simply but at least correctly, produce a compile-time error until a type witness is inserted (and observed).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)