7$: Parse '..' (incomplete '...') intelligently

[strager]

In many situations, we should parse .. as if it was ... (spread operator).

[muzoaydo]

I claim this for-hire task. I expect payment after I complete this task. I will email the quick-lint-js team if I am assigned this task.

[strager]

Here are some cases we can improve. Each example should instead say something like "missing third '.' in '...' for array spread".

let xs = [];

// error: unexpected token [E0054]
function f(..x) { }

// error: missing operand for operator [E0026]
// error: missing property name between '.' and '.' [E0053]
(..x) => {};

// error: missing operand for operator [E0026]
// error: missing property name between '.' and '.' [E0053]
f(..xs);

// error: missing operand for operator [E0026]
// error: missing property name between '.' and '.' [E0053]
[..xs];

// error: unexpected token [E0054]
({ ..xs });

I see three implementation methods:

• Detect .. during parsing. A problem with this method is that the parser can't easily distinguish between .. and . .. If there's a space between the two dots, then the message "missing third '.'" is misleading. (I guess we can check the location information. If the second . starts where the first . ended, then it's ...)
• Detect .. during lexing. A problem with this method is that the lexer can't distinguish [x..y] (which should trigger missing property name between '.' and '.' [E0053]) and [x,..y] (which should trigger the error this task is talking about).
• Treat .. as its own token type (dot_dot) during lexing. This elegantly addresses the problems with the above methods, but might introduce other problems. I don't know if a new token type is worth it. Who knows, JavaScript might add a .. token in the future anyway. 🤷‍♀️

[strager]

@muzoaydo Are you still working on this task? Do you need any help?