[
https://issues.apache.org/jira/browse/GROOVY-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9192:
-------------------------------
Description:
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).
was:
As Groovy Eclipse reuses the new Parrot parser, it's better to implement parser
error recovery for better editing experience in Groovy Eclipse.
Set optimization option {{errorRecovery}} as {{true}} to enable parser error
recovery, which is disabled by default.
> Implement 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)
