codeconsole opened a new pull request, #3248:
URL: https://github.com/apache/groovy/pull/3248
`await` and `async` have their own alternatives in the `expression` rule
(`awaitExprAlt`, `asyncClosureExprAlt`), but the operand of a cast is parsed by
`castOperandExpression`, which listed only another cast, a `postfixExpression`
and the unary operators. After a cast the two words therefore fell back to
being identifiers: `(BigDecimal) await(price)` was a call to a method named
`await` with one argument and `(Awaitable<Integer>) async { 7 }` a call to a
method named `async` with a closure. At script level that is a
`MissingMethodException`; inside an async task the failure is swallowed by the
task nobody awaits, and the code awaiting the task's result hangs (the issue
has the three reproducers; the parenthesised forms `(int) (await t)` and
`-(await t)` were fine).
`castOperandExpression` gains the two alternatives, with the same labels;
the rule declares `baseContext = expression`, so they produce the same contexts
and `AstBuilder.visitAwaitExprAlt` and `visitAsyncClosureExprAlt` apply
unchanged.
Tests: `AsyncAwaitTest` gains a cast applied to `await` with one and with
several arguments, the same inside an async task that binds a
`DataflowVariable` (the shape that hung), and a cast applied to an async
closure. On JDK 21 `AsyncAwaitTest` (277 tests) and `ParserPositiveSyntaxTest`
pass; `ParserNegativeSyntaxTest` shows only the two failures master has since
GEP-19 landed (#3247 fixes those).
Found by the eval harness of a Groovy-for-agents project: Claude Opus 5.5
wrote the cast form in every statically typed answer to a dataflow task, and
each run timed out. Candidate for `GROOVY_6_0_X` as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
