• That's a crazy amount of code, way way more than required to demonstrate the problem. At most 20 lines are needed here, which is an exceptionally high amount.
• None of the rules being discussed are even mentioned in the code! How is the code in the least bit relevant?
• The code doesn't run as no data was provided.
• Desired output is not provided.

I know a lot about P::RD, but I'm not touching this mess.

What I want, I think, is for the parser, having recognized one occurrence of job_statement, to at that point <commit> to it.

So, <commit> after each successfully parsed job_statement. Then offer an alternative that slurps up the rest of the file, as a dummy, to make the grammar match in the end.

I don't know Parse::RecDescent enough to express what I mean in code, so I'll try in Perl 6 rules, maybe that's sufficiently readable for you to translate it to your needs:

grammar Jobs {
   token TOP { ^ '$JOBS' <job_def> $ }
   role job_def {
       [
            <single_job_definiton> <commit>
            || .*   # if there is no way to parse
                    # a job definition, dummy-parse
                    # the rest of the string to prevent
                    # outright failure
       ]+
   }
}
[download]

$parser->start_rule(\$data) or warn("not a job file"), return;
while( $data ){ $parser->job_statement(\$data) }
[download]

This doesn't address the question of how to resync if you encounter a bad entry.

That is a very clever strategy.   I will ponder it carefully.

In this case, “resyncing after a syntax error” is a non-issue.   I am interested in the error messages because I am debugging the grammar.

Thanks for all your help, everyone.

I am looking at the “Eliminate Backtracking When Possible” section in Parse::RecDescent::FAQ::Original to see if it might have some bearing on my problem.

It would be a purely-recursive rule something like this:

  job_statements : job_statement <commit> job_statements(?)
                   | #NOTHING
[download]

  job_statements : job_statement <commit> job_statements
                   | job_statement
                   | #NOTHING
[download]

But I really hate to recurse like that.   If I’ve got a list of two or three hundred job_statements, as I well might, then I’ve obliged the computer to recurse two or three hundred levels deep!   (I think ...)

The trouble is, this file layout really is not well-thought-out.   (And it isn’t correctly documented, either.)   In other words, “it sucks large, yes ... but we are stuck with it.”

But I really hate to recurse like that.

job_statements : job_statement <commit> job_statements(?)
               | #NOTHING
[download]

and the less efficient

job_statements : job_statement <commit> job_statements
               | job_statement
               | #NOTHING
[download]

are both just recursive versions of

job_statements : job_statement(s?)
[download]

If you don't want the recursion, use the last.

But I really hate to recurse like that. If I’ve got a list of two or three hundred job_statements, as I well might, then I’ve obliged the computer to recurse two or three hundred levels deep!

Well, you made the choice of using a recursive descent parser.

They aren't known for making the fastests parses. Considering the number of <commit>s you have in your grammer, can't you use a limited look-ahead parser? (LL(N), LR(N), ...) No recursion nor backtracking is than needed; syntax errors are more quickly discovered, and you may have an easier time resyncing after a parsing error.

You could make <commit> behave the way it does in Perl6 by adding, for each rule that has a <commit> in one of its alternatives, a final <uncommit><reject> alternative.

Okay, I think that I have come up with a workable solution.   (Given that the only parser-tool that I have to work with, in this case, is this one ...)

Well, the first thing that I did, as you can see, is to shrink the size of the grammar-example in the original post to “just an example.”   (Sorry about that.)

Then, I came up with a production like this:

  job_list : job_statement job_list
             | #NOTHING
[download]

The rule does recurse.   When the “nothing” case is encountered (which simply means that “whatever we are looking at now, whatever it is, is not a job_statement”) the result of the production is a string consisting of the name of the nonterminal (“job_list”).   The action code (not shown) ignores that.

Well, the first thing that I did, as you can see, is to shrink the size of the grammar-example in the original post to “just an example.”

You still not clear what you want out of it.

If you simply don't want it to fail, use a production that always matches instead of using <error>.

Then, I came up with a production like this:

job_list : job_statement job_list
         | #NOTHING
[download]

will match the same as

job_list : job_statement(s?)
[download]