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)