[
https://issues.apache.org/jira/browse/GROOVY-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097430#comment-18097430
]
ASF GitHub Bot commented on GROOVY-9192:
----------------------------------------
github-actions[bot] commented on PR #2724:
URL: https://github.com/apache/groovy/pull/2724#issuecomment-5016140190
### JMH summary — classic (commit `d8f8f43`)
Speedup vs trailing 90-day baseline on gh-pages. Higher = faster.
`1.00` = in line with history. Per-benchmark ratio, geomean within group.
Time-per-op units inverted so direction is consistent. The *calibrated*
column divides out this runner's speed vs the baseline hardware, as
measured by Groovy-independent pure-Java ruler benchmarks.
| Group | Speedup | Calibrated | n |
|--------|---------|------------|---|
| bench | 0.947 × | 0.993 × | 84 |
| core | 1.214 × | 1.036 × | 77 |
| grails | 0.990 × | 0.954 × | 80 |
> ⚠️ Runner speed differs ≥15% from the historical baseline hardware for:
core-hz. Raw speedups are not meaningful for those parts — use the calibrated
column.
<sub>Runner calibration (this run vs baseline hardware): bench 0.96× (26
rulers) · core-ag 1.08× (3 rulers) · core-hz 1.28× (3 rulers) · grails-ad 1.10×
(3 rulers) · grails-ez 0.99× (3 rulers)</sub>
<sub>Baseline: <code>dev/bench/jmh/<part>/classic/data.js</code> on
gh-pages, trailing 90 days. <a
href="https://apache.github.io/groovy/dev/bench/jmh/summary.html";>Daily
dashboard</a> · <a
href="https://apache.github.io/groovy/dev/bench/jmh/";>Per-suite raw
data</a></sub>
<!
> Implement optional parser error recovery for Parrot parser
> ----------------------------------------------------------
>
> Key: GROOVY-9192
> URL: https://issues.apache.org/jira/browse/GROOVY-9192
> Project: Groovy
> Issue Type: Improvement
> Components: parser-antlr4
> Reporter: Daniel Sun
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> h2. Summary
> Add *optional* ANTLR error recovery to the Parrot (antlr4) parser so IDE
> hosts (e.g. Groovy Eclipse) can collect *multiple* syntax diagnostics in one
> pass. Default remains fail-fast (current production behaviour).
> h2. Motivation
> * Groovy Eclipse and similar tools reuse the Parrot parser for editing.
> * Today recognition failures fail-fast: the first syntax error stops
> parsing, so the editor often shows only one diagnostic per save/rebuild.
> * Editors need resynchronization after a fault so further errors in the same
> file can be reported without a full redesign of the grammar.
> h2. Requirements
> # *Opt-in only* — recovery is {*}disabled by default{*}; production
> {{groovyc}} stays fail-fast.
> # *Enable via configuration* — compiler option {{errorRecovery}} and/or
> system property {{{}groovy.parser.error.recovery{}}}.
> # *Multi-error collection* — with recovery on, recognition errors accumulate
> in {{ErrorCollector}} instead of aborting on the first fatal parse error.
> # *Preserve friendly diagnostics* — keep delimiter messages such as "Missing
> ')'", "Missing ']'", "Missing '}'" (via existing
> {{{}MissingDelimiterDiagnostic{}}}).
> # *Preserve fail-fast performance path* — SLL to LL two-stage parsing and
> bail-style cancel remain the default.
> # *No dual throwable hierarchy* — semantic failures continue to use
> {{{}GroovySyntaxError{}}}; recovery is owned by the error strategy and error
> collection path.
> h2. Proposed design
> h3. Configuration
> * {{CompilerConfiguration.ERROR_RECOVERY}} (value {{{}errorRecovery{}}})
> stored in {{getOptimizationOptions()}} (same map as other feature flags such
> as {{{}groovydoc{}}}).
> * {{CompilerConfiguration#isErrorRecoveryEnabled()}} — returns true only
> when the option is explicitly {{{}Boolean.TRUE{}}}.
> * System property: {{groovy.parser.error.recovery}} (optional bootstrap).
> {code:java}
> CompilerConfiguration config = new CompilerConfiguration();
> config.getOptimizationOptions().put(CompilerConfiguration.ERROR_RECOVERY,
> Boolean.TRUE);
> // or: -Dgroovy.parser.error.recovery=true
> {code}
> h3. Error strategies
> * Shared reporting: package-private {{AbstractFriendlyErrorStrategy}}
> ({{{}MissingDelimiterDiagnostic{}}} plus NVAE/IME messages).
> * Fail-fast (default): {{DescriptiveErrorStrategy}} — cancel with
> {{{}ParseCancellationException{}}}; {{sync}} is a no-op (SLL-friendly).
> * Recovery: {{RecoveringDescriptiveErrorStrategy}} — ANTLR default resync /
> single-token repair.
> * Factory: {{{}DescriptiveErrorStrategy.create(CharStream, boolean){}}}.
> h3. AstBuilder / compilation pipeline
> * Wire strategy from {{{}isErrorRecoveryEnabled(){}}}.
> * When recovery is on: parse with *LL only* plus error listeners (skip the
> SLL probe so recovery cannot "succeed" on a degraded tree without re-running
> LL).
> * When recovery is on: {{collectSyntaxError}} uses
> {{ErrorCollector#addErrorAndContinue}} so diagnostics accumulate; fail-fast
> still uses {{{}addFatalError{}}}.
> * After CST/AST under recovery, if errors exist, surface
> {{CompilationFailedException}} so the compile still fails with a full error
> list.
> * {{SourceUnit#buildAST}} catches {{CompilationFailedException}} as well as
> {{{}SyntaxException{}}}, keeps an empty {{ModuleNode}} when needed, so
> multi-error collection is not aborted mid-stream.
> h3. Host contract
> * *Source of truth for multi-error UI:* {{ErrorCollector}} (not a partial
> AST).
> * Recovery may still produce an incomplete tree; later AST building can add
> further diagnostics. IDEs should display all collector errors.
> h2. Compatibility
> * Default off: existing scripts, CLI, and fail-fast tests keep current
> behaviour and cost model.
> * Public additive API: {{{}ERROR_RECOVERY{}}}, {{isErrorRecoveryEnabled()}}
> (no removal of existing APIs).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
