Ability to run parsers for symbols like A*, A+, {A ","}+ and A? without introducing a dummy non-terminal

[jurgenvinju]

• add tests on Java level
• write tests on Rascal level
• wire in ability in parser and parsers feature in ParseTree.rsc
• optional adaptations to ParserGenerator.rsc
  • generate parse methods with one artifical nonterminal wrapper
  • change names of parse methods to avoid clashes with non-terminal nested classes
• fix new name collisions in generated parser code
• fix double outermost nesting of regular productions in resulting trees

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46%. Comparing base (4e22b76) to head (3dbc3f3).
⚠️ Report is 18 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##              main   #2809   +/-   ##
=======================================
  Coverage       46%     46%           
- Complexity    6718    6727    +9     
=======================================
  Files          839     839           
  Lines        66766   66767    +1     
  Branches      9983    9983           
=======================================
+ Hits         30771   30785   +14     
+ Misses       33604   33600    -4     
+ Partials      2391    2382    -9     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[arnoldlankamp]

This is probably the smallest possible change you can make to make this feature work 👍.

As a side note. In cases where the given top node's first alternative consists of more then one symbol (e.g.: S ::= AB), a result will be returned for the first symbol in this alternative (A in this example), if A matches the entire input string.

In case you'd want to add an assert or throw an exception in case an unexpected state is encountered:

• You can verify if there is only one alternative associated with any LHS if getExpects returns an array of length 1 for it.
• You can verify if an alternative consists of a single symbol, by checking if both isEndNode() returns true and getAlternateProductions() return null for the first symbol of the alternative (in this case startNode would be the node to check this for).

[arnoldlankamp]

In terms of a potential future nice to have. A cleaner way to solve this issue would be to update the parser's public interface.
The parser was originally designed to support any non-terminal node as start symbol, however it's public interface only ever accepted sorts as start symbols.

I was thinking along the lines of adding a set a builders, so you'd be able to define (and use) grammars like:

var grammar = new Grammar()

var E = Sort("E")
var Integer = Sort("Integer")

grammar.rule(E)
  .alt(left(E, "+", E))
  .alt(left(E, "-", E))
  .gt()
  .alt(left(E, "*" ,E))
  .alt(left(E, "/" ,E))
  .or()
  .alt(Integer)

grammar.rule(Integer)
  .alt(charRange(1, 9), starList(charRange(0, 9)))
    .withRestriction(follow(charRange(0, 9)))

var parser = grammar.build()

var forest = parser.parse(input, E) // Where E represents the start symbol and can be of any type

These rules would then be preprocessed when the parser is constructed and generate all the required internal data structures. This would greatly simplify the parser generator (and tests), since it would move everything related to internal implementation details over to the parser itself. In fact, you wouldn't even need to generate code if you didn't want to, since you can fairly easily map Rascal syntax types to such a format.

The good news is that the parser's internals would remain almost entirely unaffected by adding something like this. Unfortunately changing the input format is no small undertaking. Additionally we'd also need to take backward compatibility into consideration.
So not for now, but maybe later.