[
https://issues.apache.org/jira/browse/GROOVY-12306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108612#comment-18108612
]
ASF GitHub Bot commented on GROOVY-12306:
-----------------------------------------
testlens-app[bot] commented on PR #2835:
URL: https://github.com/apache/groovy/pull/2835#issuecomment-5433536784
## 🚨 TestLens detected 1 failed test 🚨
Here is what you can do:
1) Inspect the test failures carefully.
2) If you are convinced that some of the tests are flaky, you can mute them
below.
3) Finally, trigger a rerun by checking the rerun checkbox.
### Test Summary
#### [Build and test / lts \(17,
ubuntu-latest\)](https://github.com/apache/groovy/actions/runs/33031367999/job/98384412093?pr=2835)
> :test
| Test | Runs | Flakiness |
|---|---|--:|
| ClassInfoSoftModeStressTest >
softModeSurvivesRealGcClearingUnderConcurrency\(\) | ❌ | 4% 🟡 |
🏷️ Commit: fc4b9356cc6a4f3e260791ad161c433985dd22b0
▶️ Tests: 92738 executed
🟡 Checks: 19/23 completed
### Test Failures
<details>
<summary><strong>ClassInfoSoftModeStressTest >
softModeSurvivesRealGcClearingUnderConcurrency()</strong> (:test in <a
href="https://github.com/apache/groovy/actions/runs/33031367999/job/98384412093?pr=2835";>Build
and test / lts (17, ubuntu-latest)</a>)</summary>
```
org.opentest4j.AssertionFailedError: stress probe failed: dispatches=2715713
generations=117 javaInfosCollected=33/36
ERROR: mutated-1: IllegalStateException: mutated-1 observed gen 24 after
already seeing 25
==> expected: <0> but was: <1>
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:628)
at
org.codehaus.groovy.reflection.ClassInfoSoftModeStressTest.softModeSurvivesRealGcClearingUnderConcurrency(ClassInfoSoftModeStressTest.groovy:53)
```
|expected|actual|
|---|---|
|<s>0</s>|<b>1</b>|
</details>
### Rerun Controls
> [!NOTE]
> Checks are currently running using the configuration below.
Select tests to mute in this pull request:
🔲 ClassInfoSoftModeStressTest >
softModeSurvivesRealGcClearingUnderConcurrency\(\) <!
> Error tolerance is not applied to type checking errors and has no unlimited
> setting
> -----------------------------------------------------------------------------------
>
> Key: GROOVY-12306
> URL: https://issues.apache.org/jira/browse/GROOVY-12306
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
>
> The compiler's error tolerance -- the number of non-fatal errors accepted
> before compilation bails out -- is only partially wired up. Three defects,
> all verified against 6.0.0-beta-2:
> h2. 1. Tolerance is not applied to static type checking errors
> {{-t}} / {{--tolerance}} has no effect whatsoever on type checking errors, so
> there is no way to ask for fail-fast behaviour on the most common error class
> in {{@CompileStatic}} code.
> {code:java}
> @groovy.transform.CompileStatic
> class Z {
> def m0() { new Object().nope0() }
> def m1() { new Object().nope1() }
> // ... 14 such methods
> }
> {code}
> ||Command||Expected||Actual||
> |{{groovyc -t 1 Z.groovy}}|1 error|14 errors|
> |{{groovyc -t 3 Z.groovy}}|3 errors|14 errors|
> Cause: only {{ErrorCollector.addError(Message)}} performs the {{errors.size()
> >= configuration.getTolerance()}} check. {{ClassCodeVisitorSupport.addError}}
> calls {{addErrorAndContinue}} instead, so every diagnostic raised through a
> visitor bypasses the threshold, and {{StaticTypeCheckingVisitor}} overrides
> {{addError}} to call the collector directly as well.
> Errors raised through {{SourceUnit.addError}} *are* capped correctly, which
> produces a confusing split: the same flag governs class generation errors but
> silently does nothing for type checking errors.
> h2. 2. {{-t 0}} is a silent no-op, and there is no "unlimited" setting
> {{FileSystemCompiler}} guards the assignment with {{if (tolerance > 0)}}, so
> {{-t 0}} leaves the default of 10 in place with no diagnostic. There is also
> no spelling for "report everything" -- a caller wanting all errors has to
> guess a sufficiently large number. Related: {{--help}} does not state the
> default, so the option reads as unbounded-by-default when it is in fact 10.
> h2. 3. Tolerance is not exposed by the Ant task
> The Ant {{<groovyc>}} task has no tolerance attribute, so build-tool users
> have no direct route to the setting. (Gradle users can already reach it
> through {{groovyOptions.configurationScript}} with {{configuration.tolerance
> = 100}}, and embedded callers have {{setTolerance()}}.)
> h2. Fix
> # Tolerance is applied uniformly. {{ClassCodeVisitorSupport.addError}} now
> routes through the tolerance-aware {{ErrorCollector.addError}}, and
> {{StaticTypeCheckingVisitor}} does the same for the source unit's own
> collector -- but not for the temporary collectors it pushes for speculative
> checks, whose errors are routinely discarded once a candidate is ruled in or
> out.
> # A tolerance of zero or less means unlimited. The command-line option is
> held in a boxed {{Integer}} so an explicit {{0}} is distinguishable from the
> option being absent, the default is named as
> {{CompilerConfiguration.DEFAULT_TOLERANCE}} rather than repeated as a
> literal, and {{--help}} states it.
> # The Ant {{<groovyc>}} task gains a {{tolerance}} attribute. Both the forked
> and in-process paths run the same assembled argument list through the
> {{FileSystemCompiler}} parser, so emitting the option once covers both.
> The {{-t}} option has been undocumented since it was added in GROOVY-11194,
> so it is now in the groovyc option table, alongside the new Ant attribute in
> that task's table.
> h2. Behavioural change
> Type checking errors now count towards the tolerance, and the default of 10
> therefore caps them where they were previously unbounded. A compilation
> reporting 40 type checking errors will report 10 and stop. Use {{-t 0}} (or
> {{configuration.tolerance = 0}}) to restore full reporting. The default is
> deliberately left at 10 so that the documented contract, already honoured by
> parse and class generation errors, now holds for every error kind.
> This affects any caller reporting more than the tolerance through a
> {{ClassCodeVisitorSupport}} subclass, not only the compiler front ends. In
> particular {{SourceUnit.create(String, String)}} selects a tolerance of *1*,
> so a visitor driven over a source unit from that factory now stops at the
> first error; the three-argument overload takes an explicit tolerance.
> h2. Notes
> *Completeness is per-phase.* Even with unlimited tolerance, a single type
> checking error anywhere in the compilation suppresses every class generation
> error, because {{failIfErrors()}} runs at the end of each phase. Worth being
> aware of when reasoning about "report all errors", but a separate concern
> from this issue.
> *The {{groovy.errors.tolerance}} system property behaves inconsistently, but
> is best left alone.* It has existed since the original 2004 commit
> (a0a831f4e3) as a key of the {{CompilerConfiguration(Properties)}} bag, so
> whether it is reachable as a system property depends purely on the entry
> point: {{GroovyMain}} uses {{new
> CompilerConfiguration(System.getProperties())}} and honours it, whereas
> {{FileSystemCompiler}} uses the no-arg constructor, which never consults the
> property.
> {noformat}
> groovy -Dgroovy.errors.tolerance=50 ... -> 14 errors
> groovyc -Dgroovy.errors.tolerance=50 ... -> 10 errors
> {noformat}
> With the fixes above every path has a first-class route to the setting, so
> the property adds little. Promoting it to the no-arg constructor would also
> freeze it into {{CompilerConfiguration.DEFAULT}} at class-init, making it
> JVM-global and sticky across every compilation in a Gradle daemon.
> Documenting the current behaviour is preferred over changing it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
