[
https://issues.apache.org/jira/browse/GROOVY-12667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140612#comment-18140612
]
ASF GitHub Bot commented on GROOVY-12667:
-----------------------------------------
paulk-asert commented on PR #3210:
URL: https://github.com/apache/groovy/pull/3210#issuecomment-6719181647
Thanks @daniellansun.
**CI failures.** The four `testDehydrateClearsTheMemoizedClosure` failures
come from GROOVY-12669 (09ae531eaf), which landed on master after this bundle
was put together; its test pinned the `NullPointerException` that GROOVY-12667
removes, and the master merge brought it in. A dehydrated memoized closure
should fail the same way any dehydrated closure does, so I've updated the test
to expect `MissingMethodException`, folded into the GROOVY-12667 commit, and
rebased onto master (dropping the merge commit). The test still checks what it
is there for: the copy fails until rehydrated, then `rehydrate(null, p, p)`
works and the original's cache is untouched.
**Follow-ups.** Agreed, I'll file the `OWNER_FIRST`-under-`ExpandoMetaClass`
misroute, the `*_ONLY`/non-`GroovyObject` gap and the `@CompileStatic`
resolve-strategy inconsistency as separate issues. The six original PRs will
close automatically from the `Closes` lines when this merges.
**Backport.** I'd go a little wider than commits 1–2. I'd do this on the
basis that 6.0.1 candidates are regressions plus things that didn't work at all
or are obvious bugs, and most of this bundle falls into one of those:
- **GROOVY-12578/12664**: 6.0.0 regression.
- **GROOVY-12667** (both commits): a call the other candidate could answer
threw `NullPointerException` and now works; `toString`/`with` ran against
`null` in 6.0, a regression from 3.0–5.1. Where no candidate can answer, NPE
becomes `MissingMethodException`, which changes only code that already failed.
- **GROOVY-12671**: the same for properties, plus the `o1 != null` / `o2`
typo in `setPropertyTryThese`.
- **GROOVY-12675**: "Possible solutions: bcw" in error messages.
**GROOVY-12680** stays in 7.0 only: reading `Closure`'s private fields
through the metaclass has worked in every version, so hiding them changes code
that runs today. The commits above cherry-pick cleanly onto `GROOVY_6_0_X`; the
12667 commit now carries the GROOVY-12669 memoize test update with it, and the
COMPATIBILITY entries will note the 6.0.x line for the parts that go back.
> Implicit-this call in a DELEGATE_FIRST closure with a null delegate throws
> NullPointerException instead of calling the owner
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12667
> URL: https://issues.apache.org/jira/browse/GROOVY-12667
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.33, 5.0.8, 5.1.3, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> class Owner {
> def foo() { 'owner' }
> def test() {
> def c = { -> foo() }
> c.resolveStrategy = Closure.DELEGATE_FIRST
> c.delegate = null
> c()
> }
> }
> assert new Owner().test() == 'owner'
> {code}
> *Actual:* {{java.lang.NullPointerException: Cannot invoke method foo() on
> null object}}. The same happens for OWNER_FIRST with a null owner (the
> delegate is never tried), for a dehydrated closure, and for a method that
> neither candidate has (NPE instead of MissingMethodException). Since
> GROOVY-11858, {{toString()}} in such a closure returns "null" and
> {{is(null)}} returns true, because they run against NullObject.
> *Expected:* a null delegate (or owner) is skipped and the other candidate
> answers, as in Groovy 3 and as property access ({{Closure.getProperty}})
> still does. When neither answers, a MissingMethodException is thrown.
> Cause: GROOVY-7232 removed the {{instanceof GroovyObject}} check from the
> DELEGATE_FIRST and OWNER_FIRST branches of {{ClosureMetaClass.invokeMethod}},
> which also let a null delegate or owner through to
> {{InvokerHelper.invokeMethod(null, ...)}}.
> Verified: 4.0.33, 5.0.8, 6.0.0 and master affected; 3.0.25 and 2.4.15 not
> affected.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
