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 incorrect yaml positions #7946

Merged
merged 2 commits into from
Jun 5, 2023
Merged

fix incorrect yaml positions #7946

merged 2 commits into from
Jun 5, 2023

Conversation

tpetr
Copy link
Collaborator

@tpetr tpetr commented Jun 4, 2023

YAML parsing was fixed in #7918 and #7931, but I didn't catch that node start/end positions were incorrect. This was because in ctypes_read() we were returning a JS int when we should have been returning UInt32 instead.

test plan:

  • confirmed locally that the playground works properly w/ a yaml pattern
  • added unit test to confirm yaml check works and returns correct positions
  • dune build && make test succeeded

@tpetr tpetr requested a review from aryx June 4, 2023 21:22
@tpetr tpetr merged commit 6083bdb into develop Jun 5, 2023
40 checks passed
@tpetr tpetr deleted the tom/yaml-position-fix branch June 5, 2023 16:48
@@ -132,8 +132,7 @@ let mk_bracket
_;
} ) v env =
(* The end index needs to be adjusted by one because the token is off *)
(* TODO: figure out why we get an off-by-one with jsoo *)
let e_index' = if !Common.jsoo then e_index else e_index - 1 in
let e_index' = e_index - 1 in
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's how you realized there was a int32 vs int64 issue with libyaml?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not quite, the libyaml 32-bit vs. 64-bit realization was me staring at the memory offsets for long enough, and then realizing that int and size_t are the machine word size.

In this case, the ctypes glue code was incorrectly creating size_t primitives as a JS number when it should have been jsoo's UInt32 type. I didn't immediately catch this issue because the type mismatch resulted in the value being equivalent to zero (in a perfect world an exception would have been thrown)

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

Successfully merging this pull request may close these issues.

None yet

3 participants