Skip to content
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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

jtran
Copy link
Collaborator

@jtran jtran commented Jan 31, 2025

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

Screenshot from 2025-01-15 22-55-43
Screenshot from 2025-01-15 22-56-09
Screenshot from 2025-01-15 22-57-51

@jtran jtran requested a review from adamchalmers January 31, 2025 23:52
Copy link

qa-wolf bot commented Jan 31, 2025

QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

Copy link

vercel bot commented Jan 31, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
modeling-app ✅ Ready (Inspect) Visit Preview Feb 11, 2025 6:13pm

@TomPridham
Copy link
Contributor

I pushed an update that made the wording clearer in the case of random characters being in there like the [}] example that failed. I also updated the test and added some new ones for that case. I think the yarn unit tests should pass now, but I was having trouble running them locally

Copy link

codecov bot commented Feb 2, 2025

Codecov Report

Attention: Patch coverage is 98.57143% with 2 lines in your changes missing coverage. Please review.

Project coverage is 85.85%. Comparing base (d0c8311) to head (2b0944f).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/wasm-lib/kcl/src/parsing/parser.rs 98.42% 2 Missing ⚠️
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              
Flag Coverage Δ
wasm-lib 85.85% <98.57%> (+0.05%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@nrc nrc left a 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])
Copy link
Contributor

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)?

Copy link
Collaborator Author

@jtran jtran Feb 11, 2025

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);
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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);
Copy link
Contributor

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]"#;
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CRYPTIC]: Reported error is not helpful for missing comma/parentheses type errors
3 participants