RFR: 8263642: javac emits duplicate checkcast for first bound of intersection type in cast

[Vicente Romero]

On Thu, 8 Apr 2021 16:29:04 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Before the phase `desugar`, the demo `(C1 & I1) o` has **one** type-cast sub-tree, `JCTypeIntersection C1&I1`, at the syntax tree. After the phase `desugar`, the `(C1 & I1) o` becomes **three** type-cast sub-trees: `JCTypeIntersection C1&I1`, `I1`, `C1`. So at phase `Gen`, `javac` generates **three** `checkcast` according to the **three** type-cast sub-trees which causes this bug.
> 
> This patch doesn't generate `checkcast` when the type is `JCTypeIntersection` so that the problem can be solved. And a corresponding test case is added.
> 
> Another way to solve this issue is that the `TransTypes` of  the `desugar` should be modified and **two** type-cast sub-trees should be generated instead of **three**. But this way may change more code than my original patch and may cause other regression.
> 
> Thank you for taking the time to review.
> 
> Best Regards.
> --Guoxiong

Changes requested by vromero (Reviewer).

test/langtools/tools/javac/cast/intersection/DuplicatedCheckcastTest.java line 83:

> 81:                 for (Instruction instruction : code_attribute.getInstructions()) {
> 82:                     if ("checkcast".equals(instruction.getMnemonic())) {
> 83:                         checkcastNumber++;

I think that the test should check not only for the number of checkcast but also for the type the checkcast is checking against.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3399