Fix operator associativity and result units in calc()

[meziantou]

Types of Changes

Prerequisites

Please make sure you can check the following two boxes:

• I have read the CONTRIBUTING document
• My code follows the code style of this project

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• Breaking change (fix or feature that would cause existing functionality to change)
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

Description

Fixes three related defects that made calc() report silently wrong numbers. No parse error was raised in any of these cases; the wrong value was simply handed to the computed style. Every expected value below was taken from Chrome via getComputedStyle before writing the fix.

1. Repeated operators were right associative

CalcParser recursed into itself for the right operand of every operator, so the expression tree came out right associative. Chains of two or more identical operators were evaluated in the wrong order:

Expression	Chrome	Before	After
calc(10px - 2px - 3px)	5px	11px	5px
calc(100px - 10px - 20px - 30px)	40px	100px	40px
calc(100px / 2 / 5)	10px	250px	10px

Mixed precedence expressions such as calc(2 * 3px + 1px) happened to come out right, which is why this survived so long.

The four right recursive levels are replaced by two iterative loops that fold operands to the left:

expression := term (('+' | '-') term)*
term       := factor (('*' | '/') factor)*

That also collapses the artificial split between the Add/Sub and Mul/Div levels, which is what introduced the asymmetry. Serialization is unaffected, since CssText concatenates operands in order without adding parentheses, so the existing round trip tests still hold.

The loop guard additionally stops a failed left operand from being wrapped in an expression node with a null child. Previously only right was null checked.

2. Dividing equal units kept the unit

Dividing two values that share a unit cancels the unit out and yields a plain number, but CssCalcDivExpression kept the unit of the left operand, so a length landed where a number was expected:

Declaration	Chrome	Before	After
opacity: calc(10px / 20px)	0.5	0.5px	0.5
flex-grow: calc(100px / 50px)	2	2px	2
z-index: calc(100px / 25px)	4	4px	4
opacity: calc(2s / 8s)	0.25	0.25s	0.25

line-height: calc(40px / 20px) in Chrome computes to 32px, that is the number 2 times the 16px font size, which confirms the result is a number rather than 2px.

3. WithValue turned unitless lengths into pixels

CssMetricValueExtensions.WithValue builds the result via Activator.CreateInstance(type, value), and the single argument constructor of CssLengthValue defaults to Unit.Px. Any unitless length therefore came back as a length in pixels:

Declaration	Before	After
opacity: calc(1 / 4)	0.25px	0.25
flex-shrink: calc(20 / 6)	3.33333333333333px	3.33333333333333
opacity: calc(2 * 3)	6px	6

It now preserves the template's unit for lengths and falls back to the activator for the other metric types. This one also covers multiplication, not just division.