[
https://issues.apache.org/jira/browse/GROOVY-12463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128592#comment-18128592
]
ASF GitHub Bot commented on GROOVY-12463:
-----------------------------------------
testlens-app[bot] commented on PR #2988:
URL: https://github.com/apache/groovy/pull/2988#issuecomment-6259637861
## 🚨 All tests passed but jobs failed 🚨
### Failed Jobs without Test Failures
❌ [Build and test / additional
\(22\)](https://github.com/apache/groovy/actions/runs/39196265587/job/117879591798?pr=2988)
🏷️ Commit: ddf552af5c2fd3154e04c4999f79e6857bb93fa6
▶️ Tests: 92816 executed
🟡 Checks: 12/30 completed
### Rerun Controls
Click the checkbox to trigger a rerun:
🔲 **Rerun jobs**
---
_Learn more about TestLens at
[testlens.app/docs](https://testlens.app/docs/features/pr-comment/)._
> groovy-contracts: postcondition and class invariant not checked on a trailing
> implicit return when the method also has an explicit early return
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12463
> URL: https://issues.apache.org/jira/browse/GROOVY-12463
> Project: Groovy
> Issue Type: Bug
> Components: groovy-contracts
> Affects Versions: 6.0.0
> Reporter: Paul King
> Priority: Major
>
> h2. Problem
> When a non-void method has an explicit {{return}} on one path and produces
> its value through an implicit return on another, the implicit path skips the
> contract checks. Neither the {{@Ensures}} postcondition nor the class
> {{@Invariant}} is checked there, and the method returns an unchecked value.
> {code:groovy}
> import groovy.contracts.*
> class H {
> @Ensures({ result > 0 })
> int implicitAfterEarly(boolean b) { if (b) return 1; -1 }
> @Ensures({ result > 0 })
> int explicitBoth(boolean b) { if (b) return 1; return -1 }
> @Ensures({ result > 0 })
> int ifElseImplicit(boolean b) { if (b) { 1 } else { -1 } }
> }
> def h = new H()
> h.implicitAfterEarly(false) // returns -1, no PostconditionViolation
> h.explicitBoth(false) // PostconditionViolation
> h.ifElseImplicit(false) // PostconditionViolation
> {code}
> The same happens with {{@CompileStatic}} and with class invariants:
> {code:groovy}
> @Invariant({ count >= 0 })
> class K {
> int count = 0
> int dec(boolean b) { if (b) return count; count -= 5; count }
> }
> new K().dec(false) // returns -5, no ClassInvariantViolation
> {code}
> This is easy to hit with guard clauses, a common style: return early for bad
> input, then let the last expression be the result. Found while writing a
> contract for a date parser of that shape, where a 31 February result was not
> caught.
> h2. Cause
> {{AssertStatementCreationUtility.getReturnStatements}} collects the method's
> explicit {{ReturnStatement}} nodes. It runs {{ReturnAdder}}, which turns
> trailing expressions and value-producing if/else, switch and try statements
> into returns, only when that list is empty. GROOVY-12129 introduced the
> {{ReturnAdder}} delegation, but its tests do not cover a method that mixes
> the two. With any explicit return present, the trailing expression stays an
> expression statement, no assertion is woven before it, and the compiler adds
> the return later, unchecked.
> All three callers are affected:
> * {{PostconditionGenerator}}: {{@Ensures}}.
> * {{ClassInvariantGenerator}}: invariant checks on non-void methods.
> * {{AnnotationClosureVisitor.recordNonNullReturnViolations}}: the {{return
> null}} paths handed to NullChecker.
> h2. Fix
> Always run {{ReturnAdder}} before collecting the returns. {{ReturnAdder}}
> performs the conversion the compiler applies later anyway and leaves existing
> return statements unchanged. Applying it unconditionally does not change what
> the method computes; it only makes every exit path visible to the weaving.
> h2. Tests
> Added to {{ImplicitReturnPostconditionTests}} and
> {{SimpleClassInvariantTests}}:
> * trailing implicit return after an early return is checked (violation
> detected);
> * the returned values are unchanged by weaving (vacuous postcondition);
> * trailing implicit if/else after an early return is checked;
> * the same under {{@CompileStatic}}, with an {{Optional}} result;
> * the class invariant is checked on the trailing implicit path.
> Four of the five fail before the fix. The values test passes either way,
> because the bug skipped the check without changing the value. With the fix,
> the full groovy-contracts suite (364 tests) and groovy-typecheckers suite
> (356 tests) pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
