[
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
can collect *multiple* syntax diagnostics in one pass. Default remains
fail-fast (current {{groovyc}} behaviour).
h2. Motivation
* Groovy Eclipse and similar tools reuse the Parrot parser while editing.
* Recognition failures today fail-fast: the first syntax error stops parsing,
so the editor often shows only one diagnostic per rebuild.
* Editors need resynchronization after a fault so further errors in the same
file can be reported without redesigning the grammar.
h2. Goals
# *Opt-in only* — recovery is *disabled by default*; production compilation
stays fail-fast.
# *Configuration switch* — {{CompilerConfiguration.ERROR_RECOVERY}}
({{errorRecovery}}) and optional 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.
# *Friendly diagnostics preserved* — keep messages such as {{Missing ')'}} /
{{Missing ']'}} / {{Missing '}'}} via existing {{MissingDelimiterDiagnostic}}.
# *Fail-fast path unchanged* — SLL→LL two-stage parse and bail-style cancel
remain the default cost model.
# *No dual throwable hierarchy* — recovery is owned by the error strategy and
{{ErrorCollector}}, not a second exception type tree.
h2. Design
h3. Configuration
* Constant: {{CompilerConfiguration.ERROR_RECOVERY}} = {{"errorRecovery"}},
stored in {{getOptimizationOptions()}} (same map as other feature flags, e.g.
groovydoc).
* Query: {{isErrorRecoveryEnabled()}} — true only when the option is explicitly
{{Boolean.TRUE}}.
* Bootstrap: system property {{groovy.parser.error.recovery}}.
{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}} + NVAE/IME messaging).
* Fail-fast (default): {{DescriptiveErrorStrategy}} — {{recover}} /
{{recoverInline}} cancel via {{ParseCancellationException}}; {{sync}} is a
no-op (SLL-friendly).
* Recovery: {{RecoveringDescriptiveErrorStrategy}} — ANTLR default resync /
single-token repair.
* Factory: {{DescriptiveErrorStrategy.create(CharStream, boolean)}}.
h3. AstBuilder / pipeline
* Select strategy from {{isErrorRecoveryEnabled()}}.
* Recovery parse uses *LL only* with error listeners (skip the SLL probe so
recovery cannot "succeed" on a degraded tree without re-running LL).
* {{collectSyntaxError}}: recovery → {{ErrorCollector.addErrorAndContinue}};
fail-fast → {{addFatalError}}.
* Under recovery, {{AstBuilder.buildAST}} returns a (possibly partial)
{{ModuleNode}} when diagnostics are already recorded; it does *not* require
{{SourceUnit}} to swallow {{CompilationFailedException}}.
* Compile still fails: {{CompilationUnit}} / {{ErrorCollector.failIfErrors()}}
owns phase failure with the full diagnostic list.
h3. Host contract
* *Source of truth for multi-error UI:* {{ErrorCollector}} (not the partial
AST).
* Recovery may still yield an incomplete tree; later phases 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 only: {{ERROR_RECOVERY}}, {{isErrorRecoveryEnabled()}}
(no removals).
was:
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).
> 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 can collect *multiple* syntax diagnostics in one pass. Default remains
> fail-fast (current {{groovyc}} behaviour).
> h2. Motivation
> * Groovy Eclipse and similar tools reuse the Parrot parser while editing.
> * Recognition failures today fail-fast: the first syntax error stops parsing,
> so the editor often shows only one diagnostic per rebuild.
> * Editors need resynchronization after a fault so further errors in the same
> file can be reported without redesigning the grammar.
> h2. Goals
> # *Opt-in only* — recovery is *disabled by default*; production compilation
> stays fail-fast.
> # *Configuration switch* — {{CompilerConfiguration.ERROR_RECOVERY}}
> ({{errorRecovery}}) and optional 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.
> # *Friendly diagnostics preserved* — keep messages such as {{Missing ')'}} /
> {{Missing ']'}} / {{Missing '}'}} via existing {{MissingDelimiterDiagnostic}}.
> # *Fail-fast path unchanged* — SLL→LL two-stage parse and bail-style cancel
> remain the default cost model.
> # *No dual throwable hierarchy* — recovery is owned by the error strategy and
> {{ErrorCollector}}, not a second exception type tree.
> h2. Design
> h3. Configuration
> * Constant: {{CompilerConfiguration.ERROR_RECOVERY}} = {{"errorRecovery"}},
> stored in {{getOptimizationOptions()}} (same map as other feature flags, e.g.
> groovydoc).
> * Query: {{isErrorRecoveryEnabled()}} — true only when the option is
> explicitly {{Boolean.TRUE}}.
> * Bootstrap: system property {{groovy.parser.error.recovery}}.
> {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}} + NVAE/IME messaging).
> * Fail-fast (default): {{DescriptiveErrorStrategy}} — {{recover}} /
> {{recoverInline}} cancel via {{ParseCancellationException}}; {{sync}} is a
> no-op (SLL-friendly).
> * Recovery: {{RecoveringDescriptiveErrorStrategy}} — ANTLR default resync /
> single-token repair.
> * Factory: {{DescriptiveErrorStrategy.create(CharStream, boolean)}}.
> h3. AstBuilder / pipeline
> * Select strategy from {{isErrorRecoveryEnabled()}}.
> * Recovery parse uses *LL only* with error listeners (skip the SLL probe so
> recovery cannot "succeed" on a degraded tree without re-running LL).
> * {{collectSyntaxError}}: recovery → {{ErrorCollector.addErrorAndContinue}};
> fail-fast → {{addFatalError}}.
> * Under recovery, {{AstBuilder.buildAST}} returns a (possibly partial)
> {{ModuleNode}} when diagnostics are already recorded; it does *not* require
> {{SourceUnit}} to swallow {{CompilationFailedException}}.
> * Compile still fails: {{CompilationUnit}} /
> {{ErrorCollector.failIfErrors()}} owns phase failure with the full diagnostic
> list.
> h3. Host contract
> * *Source of truth for multi-error UI:* {{ErrorCollector}} (not the partial
> AST).
> * Recovery may still yield an incomplete tree; later phases 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 only: {{ERROR_RECOVERY}}, {{isErrorRecoveryEnabled()}}
> (no removals).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
