[JENKINS-66613] Correct Antlr grammar for LabelExpression

[Wadeck]

See JENKINS-66613.

The Antlr grammar used for LabelExpress (LabelExpr.g) contained flaws since more than 10 years. The first one is a nondeterminism between ATOM and IMPLIES as both could start with a -. Second point is about the ATOM being greedy by default, eating the next IMPLIES if there is no space inbetween (a->b expression is parsed as a single ATOM, while it should be a IMPLIES with two ATOMs).

Some tests are added to cover the first point and others (related to lack of spaces) to cover the second point.

💡 It should also cover JENKINS-16728 and JENKINS-22975 (and also second part of JENKINS-16734, thanks Tim).

FTR I tried different approaches while "learning" ANTLR, like Nongreedy Subrules, ending up with Explicit Lookahead as the working solution.

Bonus:

Before this PR during the build

[INFO] --- antlr-maven-plugin:2.2:generate (labelExpr) @ jenkins-core ---
[INFO] performing grammar generation [labelExpr.g]
ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005
C:\Users\Wadeck\Workspace\_core_dev\_quick\core\src\main\grammar\labelExpr.g: warning:lexical nondeterminism between rules IMPLIES and ATOM upon
C:\Users\Wadeck\Workspace\_core_dev\_quick\core\src\main\grammar\labelExpr.g:     k==1:'-'

[INFO]
[INFO] ------------------< org.jenkins-ci.main:jenkins-war >-------------------

After this PR during the build

[INFO] --- antlr-maven-plugin:2.2:generate (labelExpr) @ jenkins-core ---
[INFO] performing grammar generation [labelExpr.g]
ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005

[INFO]
[INFO] ------------------< org.jenkins-ci.main:jenkins-war >-------------------

Proposed changelog entries

• Correction of Label expression including a "implies" relationship without spaces around.

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• [n/a] For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@daniel-beck (I know you will be really happy with this one :D)

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[timja]

Does it also address https://issues.jenkins.io/browse/JENKINS-16734 ?

[Wadeck]

@timja I think the first part with the && was corrected by KK long time ago, while the second part is corrected in this PR. Good catch, will link the ticket as well ^^

[timja]

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[daniel-beck]

Thanks for taking care of this!