-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: add better errors for missing commas in arrays and objects #5210
base: main
Are you sure you want to change the base?
Conversation
QA Wolf here! As you write new code it's important that your test coverage is keeping up. |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
I pushed an update that made the wording clearer in the case of random characters being in there like the |
45a913f
to
620ea21
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5210 +/- ##
==========================================
+ Coverage 85.80% 85.85% +0.05%
==========================================
Files 94 94
Lines 33554 33676 +122
==========================================
+ Hits 28792 28914 +122
Misses 4762 4762
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
620ea21
to
4ddf3da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are much nicer messages, thanks! I think we need to get change the approach of scanning for the closing delimiter though (or do that for all delimiters in a pre-parsing pass over the tokens, which might be useful for better error messages elsewhere, but if it's a lot of work I would avoid it since long-term we probably need to rewrite the parser) to avoid performance issues and over-matching
expect(error.message).toBe( | ||
'Unexpected character encountered. You might be missing a comma in between elements.' | ||
) | ||
expect(error.sourceRange).toEqual([29, 31, 0]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer we didn't test error messages from type script, can we just remove this check (or the whole file)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
})? | ||
.end; | ||
|
||
let maybe_closing_bracket: PResult<TokenSlice<'_>> = peek(take_until(0.., "]")).parse_next(i); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a little eager to find a closing bracket - it can scan to the end of the source file(unless I misunderstand what Winnow would do) so could get a lot of false positives (as well as being bad for performance). At the least, we shouldn't do this check until we know we are recovering from an error (and even then it feels bad since we might call this function to test if this is an array). But I think for correctness the forward search should be terminated by anything which can't occur before a ]
in correct code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you're right. I can definitely move the check into the if statement on 761. How would you suggest checking for incorrect literals before the ]
? If I'm thinking about it correctly, we would need to track the literals as we progressed through the tokens.
Like, a parenthesis could be invalid, but only if it's not balanced. Same with a comma. ,,
is definitely wrong, but multiple commas aren't inherently incorrect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the closing bracket checks into the error branch. Let me know about how best to go about bailing out earlier and I can add that in as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's not easy! I don't know how best to integrate it with Winnow. Typically for this kind of recovery you come up with a set of tokens which cannot appear within the sequence, the easiest place to start is keywords. For matching delimiters you need to use your own stack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I got that working as requested I think. I didn't do anything too fancy for things like braces, brackets, and commas. Let me know if I should adjust or add anything in. I had some other comments/questions I'll leave on this PR once it's up to date with my branch
ignore_trailing_comma(i); | ||
ignore_whitespace(i); | ||
|
||
let maybe_closing_brace: PResult<TokenSlice<'_>> = peek(take_until(0.., "}")).parse_next(i); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above
@@ -3769,7 +3820,7 @@ height = [obj["a"] - 1, 0]"#; | |||
#[test] | |||
fn test_parse_member_expression_binary_expression_in_array_number_second_missing_space() { | |||
let code = r#"obj = { a: 1, b: 2 } | |||
height = [obj["a"] -1, 0]"#; | |||
height = [obj["a"] -1, 0]"#; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implies there's indentation in the KCL code, which is probably not intended
Authored by @TomPridham. Replaces/closes #5079.
closes #5055.
Adds better error messaging for missed commas in objects and arrays and adds the same missing closing bracket message for objects