Multiline signature destructuring
barneycarroll opened this issue · 6 comments
New lines seem to break signature syntax highlighting:
This is one of those tricky spots that come from having no way to see beyond the current line at any given point, a limitation of SublimeText. At "({", there’s no way to tell if it’s an object literal, arguments with destructuring, or regular assignment destructuring. In this case it’s assumed object literal at the start and doesn’t recover nicely (even after the second line, it’d still be ambiguous, just less so).
I should be able to tweak this to avoid the "invalid" scope, but unfortunately it will never be possible to actually highlight the arguments as such in a case like this :(
That's interesting. So this is limited to arrows. There is (I think?) a problem case that can be addressed within this constraint whereby the first line contains a default assignment…
That’s true, yep. There is some handling for similar cases already that tries to "recover", which is what we’ll need to introduce here. This one is complicated a bit extra because at that stage we can know it’s an object binding pattern, but not whether it’s function parameters or an assignment expression (not detectable until the fifth line).
Oh I see… So there's a dilemma of erring on the side of caution (we can't tell that this is valid code) and trusting the author (param assignment indicates a signature, we'll assume you know what you're doing until proven otherwise)… Because if it is an object literal, leaving the syntax error to the last line will be totally misleading 🤔
Well, not quite that — I would say the current behavior is a bug / oversight. The = disambiguates the {} structure as a binding pattern, since it would only be valid there, and we can proceed as if that was what we thought it was all along from that point on with a bit of sneakiness (though there’s no way to go back and correct the scopes for stuff prior). But the = does not tell us it’s parameters; it could still ultimately be an assignment expression, and we don’t know until we see either = or =>:
({
foo=bar
} = baz);
So even once we handle recovery here, foo will not be scoped as variable.parameter, it will be scoped as variable.other.readwrite.
@barneycarroll There’s now an escape route for recovering from ambiguity in this position. Although it will always get the first n lines scoped wrong, and it won’t know in a case like this that the binding pattern belongs to parameters, it now at least knows that if it sees an assignment, it should switch to interpreting the remainder as a binding pattern; and existing recovery logic already takes care of the arrow.
