Fix IN operator after case expression

[Dinesh0204]

• Added lookahead logic in SimpleConditionalExpression()
• Handles CASE, COALESCE, NULLIF, and parenthesized expressions
• Added comprehensive test coverage
• Fixes Querybuilder: Expected =, <, <=, <>, >, >=, !=, got 'IN' #12178

[mpdude]

Could you please review the EBNF documentation section and make sure it is in sync with your fix?

[Dinesh0204]

Could you please review the EBNF documentation section and make sure it is in sync with your fix?

Hii,
I have Updated grammar to support CASE, COALESCE, and NULLIF expressions with IN/NOT IN operators.

[Dinesh0204]

Hi @mpdude,
If my PR looks good, could you please add the hacktoberfest-accepted label? It’ll help it count for Hacktoberfest. Thanks! 😊

[mpdude]

For sure you have picked one of the tougher items here 😄

I have been chewing on this for quite some time now, and I am not convinced that this is the right approach to tackle it.

Looking at the grammar as it is documented right now, everything is already there: The SimpleConditionalExpression has InExpression as one possible production, which is defined as ArithmeticExpression ["NOT"] "IN" "(" .... ArithmeticExpression, in turn, also includes CaseExpression (through intermediate steps).

This should also cover things like WHERE 1 + CASE WHEN 1=1 THEN 2 ELSE 3 END IN (3).

The problem is that the implementation in \Doctrine\ORM\Query\Parser::SimpleConditionalExpression() is not up to that. We need a more sophisticated way of peeking ahead to decide which production rule to invoke next.

It's been more than two decades since I had the theory on parsers in university... Does that have something to do with the "first set", i. e. for all possible productions on the right hand side of SimpleConditionalExpression, we need to find the first terminal token that uniquely identifies the next production method to invoke?

Alternatively: I noticed that BetweenExpression, ComparisonExpression and InExpression all start with ArithmeticExpression. Would it help if factor this out into a grammar construct on its own?

[Dinesh0204]

Thanks for the detailed breakdown!

I see your point now — it’s more about how the parser decides which production to invoke rather than just fixing one case.

I’ll try to dig deeper into this and get a better understanding of the lookahead and first-set logic.
If you could point me to parts of the code or other resources I should focus on, that’d be really helpful.
Really appreciate you taking the time to explain all this.