Reuse getBinaryOperatorPrecedence#22844
Conversation
|
@rbuckton Also, I tried adding an assertion and the |
| } | ||
| } | ||
|
|
||
| /* @internal */ |
There was a problem hiding this comment.
I'd rather we keep to a consistent series of values for operator precedence, so we don't in the future accidentally try to compare the result from getBinaryOperatorPrecedence to getOperatorPrecedence. As far as the parser is concerned, it only cares whether the new precedence is higher than the old one and is greater than 0.
|
|
||
| case SyntaxKind.AsteriskAsteriskToken: | ||
| // This would be 15 if we used the below line instead, which changes emit for the test `emitExponentiationOperator4`. | ||
| return 14; |
There was a problem hiding this comment.
Its probably ok to bump this up to 15 since that reflects the current spec, though we should probably also bump the precedence of anything 15 or above up by one.
|
@Andy-MS Yeah, ExclamationToken and TildeToken can be removed since they're actually PrefixUnaryExpression and are handled by that case instead. |
|
|
||
| /* @internal */ | ||
| export function getBinaryOperatorPrecedence(kind: SyntaxKind): number { | ||
| switch (kind) { |
There was a problem hiding this comment.
minor nit: It's a bit odd to read getOperatorPrecedence in descending order then see getBinaryOperatorPrecedence in ascending order. We might want to change the order of one or the other to be consistent.
There are two functions that do basically the same thing.
I did notice that they return different results for
**; had to preserve the old behavior to prevent a baseline from changing, but it may be better for the baseline to change if you write(void --temp) ** 3;; may be worth it to just change the baseline though, which seems harmless.