Withdrawn: 8213766: Assertion error in TypeAnnotations$TypeAnnotationPositions.resolveFrame

[duke]

On Sun, 17 Jan 2021 16:52:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This regression is caused by [PATCH-8078093](https://github.com/openjdk/jdk/commit/981c6dc2989b66f3691090c9f81e23d2b0a00087).
> 
> The method `DeferredAttr$DeferredAttrNode$StructuralStuckChecker.canLambdaBodyCompleteNormally` uses `attribSpeculativeLambda`. Later, the `ArgumentAttr.visitLambda(JCLambda that)` would be invoked, which sets the `ExplicitLambdaType.tree.type` to its `ExplicitLambdaType`. Note: currently, the `ExplicitLambdaType.tree` was not attributed and only the `ExplicitLambdaType.speculativeTree` was attributed.
> 
> Then, `DeferredAttr$RecoveryDeferredTypeMap.typeOf` would not invoke the method `recover` to attribute the `ExplicitLambdaType.tree` because the `owntype` is not equal to `Type.noType`. The code and some comments are shown below for you.
> 
> 
> protected Type typeOf(DeferredType dt, Type pt) {
>     Type owntype = super.typeOf(dt, pt);  // The `super.typeOf(dt, pt)` returns the `ExplicitLambdaType` which is set previously.
>     return owntype == Type.noType ?
>         recover(dt, pt) : owntype; // Here, the method `recover` is not invoked because `owntype == Type.noType` returns false.
> }
> 
> 
> Because the tree is not attributed, some regressions will occur, including this bug.
> 
> Although I found the cause of this bug, I think my patch is the simplest solution but it may be not the best solution.
> 
> Another solution is that method `DeferredAttr$DeferredAttrNode$StructuralStuckChecker.canLambdaBodyCompleteNormally` uses other way instead of using `attribSpeculativeLambda`. The old way which is before PATCH-8078093 is a candidate.
> 
> Any better solution is appreciated. Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

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

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