Preprocessor: simple support for precedence parentheses in #if evaluation

[liamdon]

Allows us to do things like:

#if (defined(A) || defined(B)) && defined(C)

or:

#if (defined(A) && INDEX == 3) || (defined(B) && INDEX > 10)

See more examples in preprocessor.test.mjs.

I tried to keep the implementation simple and similar to the current scanning approach, no AST, basically a recursive evaluation of the subexpressions while being aware of the parens in defined(). We don't strongly verify that all the parens match. I think the recursion is probably OK since we are unlikely to have deep nested parens in these expressions (I hope).

To facilitate the implementation, I added support for boolean literals true and false, which we use to replace subexpressions. If you think there are downsides to this, happy to rethink the approach.

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

[Copilot]

Pull Request Overview

Adds support for explicit parentheses in #if expressions to control operator precedence and updates tests to cover these new scenarios.

• Handle true/false literals in expression evaluation
• Introduce processParentheses to recursively evaluate sub-expressions while ignoring defined() parens
• Add multiple test cases for different parentheses precedence and nesting patterns

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
test/core/preprocessor.test.mjs	Add tests PREC1–PREC9 to verify various parentheses precedence and nesting behaviors
src/core/preprocessor.js	Support boolean literals and implement processParentheses, integrate into evaluate

Comments suppressed due to low confidence (2)

src/core/preprocessor.js:576

• Update the JSDoc to specify the return shape more precisely, e.g. @returns {{expression: string, error: boolean}}, so consumers know exactly which properties to expect.

     * @returns {object} Returns an object containing the processed expression and an error flag.

test/core/preprocessor.test.mjs:174

• [nitpick] This comment is indented unevenly compared to the surrounding lines. Align it with the other test comments for consistency.

       // Spaces in and around precedence parens

[mvaligursky]

This looks pretty good, and is reasonably simple, thanks!
My worry is that processParentheses executes each time, and has non-zero cost. I'd like to have as many early outs as possible, as out preprocessing of large shaders is already costing us about 1ms or so on desktop. Ideally this would stay as cheap as possible.

[liamdon]

@mvaligursky thanks for taking a look!

I'd like to have as many early outs as possible

Good point - what do you think of adding this? We quickly check if there is any ( excluding those in defined(), and only in that case do we run the parentheses path. There is still a small additional cost for every #if evaluation, but I don't think it's much.

Regarding overall performance, I do see some opportunities for optimization without fundamentally changing the simple scanning approach - we can reduce string concatenation, remove some allocations and early exit where possible. I will propose some optimizations in a separate PR.