PartitionNumberPattern fails to properly handle mathematical values vs. Number/BigInt

[gibson042]

trafficstars

cf. https://github.com/tc39/ecma402/pull/645#r784295285

FormatNumericToString expects a Number or BigInt value, while x is a mathematical value that AFAICT might suffer output-affecting lossiness if converted.

And similar problems in later steps (in which whether or not x is a mathematical value is dependent upon whether or not the original input was finite!)

…

I think the best fix would be updating FormatNumericToString/GetNumberFormatPattern/PartitionNotationSubPattern/etc. to accept new parameters allowing them to identify special non-mathematical Number values such as negative zero and infinities and NaN.

[gibson042]

https://github.com/tc39/ecma402/pull/651#pullrequestreview-869935114

• FormatNumeric is documented to accept x (which must be a Number or BigInt value), but FormatDateTimePattern incorrectly invokes it with mathematical values.
• FormatNumeric then sends it to PartitionNumberPattern, which also expects x (a Number or a BigInt).
• PartitionNumberPattern handles finite x by sending it to ComputeExponent (which implicitly and incorrectly treats it as a mathematical value and returns a mathematical value) and FormatNumericToString, replacing x with the [[RoundedNumber]] slot of the record returned by FormatNumericToString.
  • FormatNumericToString accepts x (which must be a Number or BigInt value), but incorrectly performs some operations upon it that are only valid with mathematical values. It replaces x with a mathematical value from the [[RoundedNumber]] slot of a record returned by either ToRawPrecision or ToRawFixed, and then returns either that mathematical value or its negation in [[RoundedNumber]].
• Back in PartitionNumberPattern, x could be either the supposedly Number/BigInt input or a mathematical value from FormatNumericToString.
• PartitionNumberPattern sends x to GetNumberFormatPattern, which performs some operations upon it that are only valid for mathematical values and others that can only succeed if it is a Number.
• PartitionNumberPattern then sends the type-confused x to PartitionNotationSubPattern, the current object of this PR, which expects x (which is a numeric value after rounding is applied) and is sufficiently vague in its treatment that no further specification seems required.

[anba]

#822 should fix this issue.