Thank you for your contribution.
Existing Tests fail, please ensure the complete test suite is running through before sending PRs.

If also do not understand why you would like to catch ConcatExpression first when there is already a general Expression in the second branch.

Thank you for your contribution. Existing Tests fail, please ensure the complete test suite is running through before sending PRs.

If also do not understand why you would like to catch ConcatExpression first when there is already a general Expression in the second branch.

I'm sorry for tests, for some reason some tests have been failed in my environment. I'll try to fix it asap. Which build system should I use? Gradle or Maven?

About your second question.
The reason is that in an ELSE part we check use LOOKAHEAD(3, {!interrupted}) and as I understand the execution will go throught LOOKAHEAD(3, {!interrupted}) elseExp=CaseWhenExpression() insead of elseExp=SimpleExpression(). To avoid an expensive LOOKAHEADs I decided to add additional ConcatExpression (the LOOKAHEAD(ConcatExpression()) looks cheaper.).

If I understand incorrectly, please tell me and I'll find another solution

I've fixed tests, but the solution of my core problem has changed. I think, It will be a bit slower then previous, but THEN part in WhenThenSearchCondition works similar.

The problem has been occurred because the ConcatExpression (and a lot of other) uses * instead of + and catches single S_IDENTIFIER instead of full concat expression. I've tried to change this behaviour, but many parts of grammar use it.

The problem has been occurred because the ConcatExpression (and a lot of other) uses * instead of + and catches single S_IDENTIFIER instead of full concat expression.

From what I can see, your fix is likely correct since we need to always test the most complex possible interpretation first.
This is counter intuitive, because from a performance perspective one would like to look for the simplest interpretation before diving into unlikely complex structures.

Example: a + b + c + d
Will be parsed as (a + b + c) + d since (a + b) + c + d would left the parser stranded.

You're right. I forgot to delete LOOKAHEAD(3) and it this will be exactly the same as part THEN. Will this snippet good or do you mean sth else?

        <K_ELSE>
        (
              LOOKAHEAD({getAsBoolean(Feature.allowComplexParsing) && !interrupted}) elseExp=Expression()
              | elseExp=SimpleExpression()
        )

Could you explain me, why did you close the PR? I really need the fix this problem. If my fix is not correct by performance reasons I'll try to fix it in some another way.
I thought if you use the same way for the THEN part, it will be ok for the ELSE part too (why not?). This is snippet for THEN:

<K_THEN>
    (
        LOOKAHEAD({getAsBoolean(Feature.allowComplexParsing) && !interrupted}) thenExp=Expression()
        |
        thenExp=SimpleExpression()
    ) 

As an example I can try to rewrite the concat function to solve this problem. It will be a bit more complex but it will work faster

Apologies, I actually believed to have MERGED it!
At least this was what I wanted to do.

Thank you, please wait for 5 min, I'll delete LOOKAHEAD(3).