[
https://issues.apache.org/jira/browse/GROOVY-12400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114489#comment-18114489
]
ASF GitHub Bot commented on GROOVY-12400:
-----------------------------------------
github-actions[bot] commented on PR #2923:
URL: https://github.com/apache/groovy/pull/2923#issuecomment-5642372175
### JMH summary — classic (commit `de56f2c`)
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.954 × | 1.050 × | 124 |
| core | 1.009 × | 0.947 × | 108 |
| grails | 1.024 × | 0.987 × | 80 |
No benchmark is ≥1.5× slower than its 90-day baseline.
<sub>Runner calibration (this run vs baseline hardware): bench 0.92× (27
rulers) · core-ag 1.14× (3 rulers) · core-hz 0.95× (3 rulers) · grails-ad 0.97×
(3 rulers) · grails-ez 1.10× (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>
<!
> Add an inline Antlr4 parser covering-set with XML AST dumps
> -----------------------------------------------------------
>
> Key: GROOVY-12400
> URL: https://issues.apache.org/jira/browse/GROOVY-12400
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> The Antlr4 parser is covered mainly by resource files under
> {{src/test-resources/core}} and {{fail}}, driven from {{GroovyParserTest}}
> and {{SyntaxErrorTest}}.
> h3. Problem
> * Positive coverage is spread across many resource files, so a single grammar
> production is hard to find and to pin down.
> * A successful {{CONVERSION}} is not the same as a correct AST: node type,
> operators, and source positions can still be wrong.
> * Negative coverage often points at a file under {{fail/}} instead of locking
> the caret diagnostic next to the snippet.
> h3. Approach
> Add two JUnit 5 classes distilled from the groovy-parser (Parrot) lab corpus,
> with Groovy source inlined in each test method (the same shape as
> {{SyntaxErrorTest}}'s missing-delimiter cases).
> * {{ParserPositiveSyntaxTest}} — valid snippets compiled through
> {{CONVERSION}}. Assert a pretty-printed XML dump of the module AST, with
> {{line}} / {{column}} / {{lastLine}} / {{lastColumn}} on every node
> ({{AstXmlDumper}}).
> * {{ParserNegativeSyntaxTest}} — invalid snippets. Assert the full caret
> diagnostic via {{expectParseError}}.
> * Helpers on {{TestUtils}}: {{parseModule}}, {{expectAst}}, {{dumpAst}},
> {{expectParseSuccess}}.
> Classic Groovy snippets were cross-checked against groovy-parser's Antlr2
> parser. Constructs Antlr2 cannot parse (records, switch expressions, {{var}},
> {{outer.new Inner()}}, and similar Parrot additions) lock the Antlr4 AST.
> {{XStreamUtils.toXML}} is extracted as the in-memory form of
> {{groovy.ast=xml}}. The covering-set dump is a compact XML visitor instead:
> reflecting the whole {{ModuleNode}} graph is too noisy (and brittle on modern
> JDKs) for inline assertions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
