[parser] Add support for slice notation#10596
Conversation
# Conflicts: # packages/babel-parser/test/fixtures/experimental/slice-notation/invalid-arg-bigint-literal/input.js # packages/babel-parser/test/fixtures/experimental/slice-notation/invalid-arg-bigint-literal/options.json # packages/babel-parser/test/fixtures/experimental/slice-notation/invalid-arg-binary-expression/input.js # packages/babel-parser/test/fixtures/experimental/slice-notation/invalid-arg-binary-expression/options.json # packages/babel-parser/test/fixtures/experimental/slice-notation/invalid-arg-unary-expression-plus/input.js # packages/babel-parser/test/fixtures/experimental/slice-notation/invalid-arg-unary-expression-plus/options.json
| validate: assertNodeType("Expression"), | ||
| }, | ||
| lower: { | ||
| validate: assertNodeType( |
There was a problem hiding this comment.
consider to use a custom validator function which aligns with parser.checkSliceArgument.
There was a problem hiding this comment.
I realize that @babel/parser and @babel/types does not depends on each other, which means it is currently not feasible to share routines between them. I would leave it as-is.
| (expr.type === "UnaryExpression" && | ||
| expr.operator === "-" && | ||
| expr.extra?.parenthesized !== true && | ||
| this.isSliceSimpleArgument(expr.argument)) |
There was a problem hiding this comment.
I don't think -foo is allowed, but -Infinity should be allowed, although they are syntactically equivalent.
There was a problem hiding this comment.
I don't think that -Infinity is valid, since it is currently restricted to Identifiers and DecimalDigits (https://github.com/tc39/proposal-slice-notation#can-the-upper-bound-lower-bound-or-the-step-argument-be-an-arbitrary-expression).
Althought, the readme itself contracdits it by using negative numbers. Also, there is tc39/proposal-slice-notation#16 which didn't receive a response.
I am ok either with the current status of this PR, or with making it more restrictive and only allow - NumericLiteral. Since this is a stage 1 proposal, it's expected that we will fix it when the semantics are clearer.
There was a problem hiding this comment.
If - NumericLiteral is allowed, it is strange that - Infinity is not allowed given that Infinity is allowed.
I tend to making it restrictive without the loss of expressive power. Since - Infinity could not be expressed further simple, I suggest we support it unless the proposal explicitly bans -Infinity.
|
Recently Slice annotation has drafted minimal spec text: tc39/proposal-slice-notation#35 Abandoning this PR due to syntax changes. |
This PR adds parser support for Slice Notation A new node type
SliceExpressionis introduced to separate slice notation fromMemberExpression.Note that the proposal does not support free-form range, e.g.
[1:4:2]and slice arguments other than identifier or numeric literals, e.g.a[1:(a.length - 2)]. Support for negative number is also added for completeness because it is modelled as anUnaryExpressioninstead of aNumericLiteral.