Update operator precedence table

[jrfnl]

Updates the table to match the information per the parser.

This adds entries for:

• =>
• include, include_once, require, require_once
• fn
• throw

Ref: https://github.com/php/php-src/blob/2e2416825d2270d256f7597904e14e386cc0d854/Zend/zend_language_parser.y#L54-L82
Ref: https://github.com/php/php-src/blob/82a15338e298142f52854b64d803695d4e5252df/Zend/zend_language_parser.y#L53-L82 (Sept 2026)

Fixes ++Related to++ #2622

[Girgias]

@iluuu1994 could you double-check the accuracy?

[iluuu1994]

I think this precedence is there exclusively to disambiguate [yield $expr => $expr]. All other uses of => are unambiguous due to braces.

[bwoebi]

That's correct.

[jrfnl]

I've updated the link block to only mention yield and linked to the language page for that.

[iluuu1994]

PREC_ARROW_FUNCTION is used for the backup flags, rather than the global expression precedence. I think this can be dropped.

[iluuu1994]

Maybe @bwoebi can verify, I don't know exactly how %prec works in Bison. Maybe it's there to disambiguate fn() => (1 + 2) vs (fn() => 1) + 2

[bwoebi]

PREC_ARROW_FUNCTION is actually defining the real precedence, but it's not about +, but about the logical operators. If it weren't for %precedence PREC_ARROW_FUNCTION, fn() => 1 or 2 would be (fn() => 1) or 2. Basically overriding the precedence of the T_DOUBLE_ARROW and resolving the s/r conflict with yield.

[bwoebi]

Also, the precedence does not really apply to fn, but to the T_DOUBLE_ARROW used in a fn() expression. (backup_fn_flags is explicitly at the place it is, to apply it's precedence there, exactly where the => is.)

[jrfnl]

Hmm.. how should I change this in that case ? Cause that sounds like it should be a double arrow, but then we'd end up with the double arrow twice in the table, once for yield and once for fn. Did I understand that correctly ? And is that what you'd like me to change it to ?

[iluuu1994]

Sorry for the late response. I suppose this case is somewhat special, in that the precedence is only applies in the arrow function context. Maybe we can make that clear by using fn (...) => as the operator, or we just leave this out as an implementation detail.

I.e. we're trying to decrease the precedence of => in that context to something lower than T_LOGICAL_*, so that fn() => 1 or 2 is parsed as fn() => (1 or 2) instead of (fn() => 1) + 2 (thanks Bob for the explanation!).

[jrfnl]

Anything I can do to move this forward ?

[lacatoire]

@jrfnl Sorry for the delay. The precedence table has moved since this pull request was opened: language/operators.xml was split by #2799, and the table now lives in language/operators/precedence.xml. That is what the conflict comes from.

[jrfnl]

@jrfnl Sorry for the delay. The precedence table has moved since this pull request was opened: language/operators.xml was split by #2799, and the table now lives in language/operators/precedence.xml. That is what the conflict comes from.

Thanks for the pointer, but that didn't answer my question, which I asked well before a conflict ever got created for this PR.

Either way, I'll rebase the PR while keeping the current page split in mind to get rid of the conflict.
I'll also re-compare against the precedence table just in case something new was introduced and not documented yet.

[jrfnl]

Oh and the underlying issue (throw missing from the precedence table) this PR was trying to solve has been solved by another PR #5083 since.... though this PR still has value for the other things it does....

[lacatoire]

PREC_ARROW_FUNCTION is attached to the empty backup_fn_flags rule, which sits after expr in the arrow function rule, so what it governs is where the body stops, not how => binds:

• zend_language_parser.y#L1401-L1402, T_DOUBLE_ARROW backup_fn_flags expr backup_fn_flags
• zend_language_parser.y#L1420-L1421, backup_fn_flags: %prec PREC_ARROW_FUNCTION %empty
• zend_language_parser.y#L53-L56, the declaration, between T_THROW and T_INCLUDE, hence below T_LOGICAL_OR

At fn() => 1 • or 2 the parser chooses between reducing that empty rule and shifting or; since PREC_ARROW_FUNCTION is below T_LOGICAL_OR it shifts. That is a different thing from the => of yield, whose precedence is carried by the token itself in L1383 (T_YIELD expr T_DOUBLE_ARROW expr) and declared at L61.

Putting => in the operator column for both rows therefore reads as two contradictory precedences for one token, which is what makes the entry look odd. The effect is still worth a row, since it is the one case the table cannot currently predict:

$x = 1 or 2;            // $x is 1                    -> ($x = 1) or 2
yield 'k' => 1 or 2;    // yields 1                   -> (yield 'k' => 1) or 2
fn() => 1 or 2;         // Closure, body returns true -> fn() => (1 or 2)

Naming the construct instead of the token says it without the contradiction. The wording holds for every operator: no binary operator is declared below PREC_ARROW_FUNCTION, only T_THROW, which cannot follow an expression anyway.

Suggested change

	<entry><literal>=&gt;</literal></entry>
	<entry><link linkend="functions.arrow">fn arrow</link> disambiguity</entry>
	<entry><literal>fn</literal></entry>
	<entry>
	The body of an <link linkend="functions.arrow">arrow function</link>
	extends as far to the right as possible
	</entry>

The row's position is right as it stands and should not move: between include/require and throw.

[jrfnl]

@lacatoire This has been discussed before above: #2625 (comment) - also your take reads as AI generated.

[lacatoire]

Got it, it's the T_DOUBLE_ARROW, and it would appear twice. Let's go with iluuu1994's first suggestion. Write the operator as fn (...) => rather than a bare =>, so the two rows can't be confused.
The behaviour is worth the row: fn() => 1 or 2 puts the or inside the body, which nothing else in the table lets you predict. I'll merge as soon as you've rebased.