[ 
https://issues.apache.org/jira/browse/GROOVY-12559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134502#comment-18134502
 ] 

ASF GitHub Bot commented on GROOVY-12559:
-----------------------------------------

paulk-asert commented on PR #3087:
URL: https://github.com/apache/groovy/pull/3087#issuecomment-6510120674

   Thanks @jdaugherty, the diagnosis is right and the fix is at the right 
level. `TernaryExpression.getType()` now agrees with 
`StatementMetaTypeChooser.resolveType()` about class literals, so a nested 
ternary is typed the way the bytecode writer types its branches. Static 
compilation is unaffected because it uses its own inferred type.
   
   I probed a few more shapes against 4.0.33, 5.1.3, 6.0.0 and master, with and 
without this PR:
   
   | Shape | 4.0.33 | 5.1.3 / 6.0.0 / master, indy | 5.1.3 / 6.0.0, classic | 
this PR |
   |---|---|---|---|---|
   | reported case (return, typed local, argument, `First.class` form, 
`@TypeChecked`) | ok | ClassCastException | ok | ok |
   | `(a ? First : Second) ?: (b ? Third : Fourth)` | ok | ClassCastException | 
ok | ok |
   | `b ? (First ?: Second) : (Third ?: Fourth)` | ok | ClassCastException | ok 
| ok |
   | `(a ? First : Second) ?? (b ? Third : Fourth)` (master only) | – | 
ClassCastException | – | ok |
   | `a ? (b ? First : Second) : marker` (`Marker marker`) | ok | 
GroovyCastException | **GroovyCastException** | ok |
   | `a ? (b ? String[] : Integer[]) : (b ? Long[] : Short[])` | ok | 
GroovyCastException | **GroovyCastException** | ok |
   
   So `?:` and `??` (both `ElvisOperatorExpression`, a `TernaryExpression`) are 
fixed with no further change. The last two rows also fail with classic call 
sites, so the problem isn't limited to indy. That's worth a note on the JIRA, 
and it strengthens the case for the backports.
   
   Could you add those shapes to the test? Something like:
   
       @Test
       void testNestedTernaryOfClassLiteralsIsJavaLangClass() {
           assertScript '''
               interface Marker {}
               class First implements Marker {}
               class Second implements Marker {}
               class Third implements Marker {}
               class Fourth implements Marker {}
   
               String name(Class<?> type) { type.simpleName }
   
               boolean a = false, b = true, c = true
               assert name(a ? b ? First : Second : c ? Third : Fourth) == 
'Third'
               assert name(b ? (a ?: c ? First : Second) : Third) == 'First'
   
               Class<?> chosen = a ? b ? First : Second : c ? Third : Fourth
               assert chosen == Third
   
               // Elvis operands
               chosen = (a ? First : Second) ?: (c ? Third : Fourth)
               assert chosen == Second
               chosen = a ? (First ?: Second) : (Third ?: Fourth)
               assert chosen == Third
   
               // a class literal versus an instance of the class it names
               Marker marker = new Fourth()
               Object either = b ? (c ? First : Second) : marker
               assert either == First
   
               // array class literals
               chosen = a ? (b ? String[] : Integer[]) : (b ? Long[] : Short[])
               assert chosen == Long[]
           '''
       }
   
   On master only, add the null-coalescing form as well:
   
               chosen = (a ? First : Second) ?? (c ? Third : Fourth)
               assert chosen == Second
   
   Nit: in `TernaryOperatorsTest` the static import sits above `import 
java.util.regex.Pattern`. Please move it below the regular imports.




> Ternary of two ternaries of class literals is cast to the classes' common 
> supertype under invokedynamic
> -------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-12559
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12559
>             Project: Groovy
>          Issue Type: Bug
>          Components: Compiler
>    Affects Versions: 5.1.3, 6.0.0
>            Reporter: James Daugherty
>            Priority: Major
>
> Since 5.0.0-alpha-4 (GROOVY-10936) the type of a ternary expression is the 
> common supertype of its branches' types. A class literal's type is the class 
> it names, not {{java.lang.Class}}, so a ternary that chooses between two 
> ternaries of class literals
> {code:groovy}
> interface Marker {}
> class First implements Marker {}
> class Second implements Marker {}
> class Third implements Marker {}
> class Fourth implements Marker {}
> class Chooser {
>     Class<?> choose(boolean a, boolean b, boolean c) {
>         a ? (b ? First : Second) : (c ? Third : Fourth)
>     }
> }
> assert new Chooser().choose(false, true, true) == Third
> {code}
> is typed as the classes' common supertype, {{Marker}}. The chosen {{Class}} 
> object is then converted _from_ {{Marker}} wherever it is used: returned, 
> passed as an argument, or assigned to a typed variable. With invokedynamic 
> that conversion is a {{cast}} call site declared as {{(Marker)Class}}, and 
> linking it casts the {{Class}} object to {{Marker}}:
> {noformat}
> java.lang.ClassCastException: Cannot cast java.lang.Class to Marker
> {noformat}
> Groovy 4, and Groovy 5 and 6 with classic call sites, return the chosen 
> class. A single-level ternary of class literals, {{a ? First : Second}}, is 
> unaffected, because the bytecode writer resolves a class literal operand to 
> {{Class<First>}} itself; a ternary's own type is consulted only when it is an 
> operand of another ternary. A Grails application moving from classic call 
> sites to invokedynamic (the Grails 9 default) meets this in code that picks a 
> class by conditions.
> *Reproducer:* 
> https://github.com/jdaugherty/groovy-ternary-class-literal-reproducer 
> ({{./run.sh 4.0.33 5.1.3 6.0.0}}): returning the chosen class and passing it 
> as an argument both fail on 5.1.3 and 6.0.0 with indy, and pass on 4.0.33 and 
> with classic call sites.
> *Cause:* {{TernaryExpression.getType()}} returns 
> {{WideningCategories.lowestUpperBound()}} of its branches' {{getType()}}, and 
> {{ClassExpression.getType()}} is the class the literal names. 
> {{BinaryExpressionHelper.evaluateTernaryExpression()}} types each branch with 
> {{StatementMetaTypeChooser.resolveType()}}, which answers {{Class<T>}} for a 
> class expression but {{getType()}} for a nested ternary. So the inner 
> ternaries are typed {{Marker}}, the outer ternary's common type is 
> {{Marker}}, and the operand stack carries {{Marker}} for a value that is a 
> {{Class}}. The conversion to {{Class}} is then written as {{invokedynamic 
> cast:(LMarker;)Ljava/lang/Class;}}, whose method type makes the JVM cast the 
> argument to {{Marker}} before the call site sees it. Classic call sites 
> convert the value to {{Class}} directly and accept it.
> *Proposed fix:* in {{TernaryExpression.getType()}}, give a class literal 
> operand the type {{Class<T>}}, as {{StatementMetaTypeChooser.resolveType()}} 
> does, so a ternary of class literals is typed {{Class}} wherever it appears. 
> A patch with a test follows as a pull request against master, with backports 
> for the 6.0.x and 5.1.x lines.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to