[
https://issues.apache.org/jira/browse/GROOVY-12306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108625#comment-18108625
]
ASF GitHub Bot commented on GROOVY-12306:
-----------------------------------------
testlens-app[bot] commented on PR #2835:
URL: https://github.com/apache/groovy/pull/2835#issuecomment-5434141458
## ✅ All tests passed ✅
🏷️ Commit: 109fa297c89c0de5e757808b337da40f8874fffd
▶️ Tests: 113332 executed
⚪️ Checks: 31/31 completed
---
_Learn more about TestLens at
[testlens.app/docs](https://testlens.app/docs/features/pr-comment/)._
> 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)
