Formatting ReScript file fails with error #2820
Labels
Comments
bryphe
added
bug
|
Thanks @dcalhoun for all the details and the screenshot. Very helpful! I pushed up a fix for the parse exception - #2825 - we weren't handling some types of numerical values correctly in our JSON parsing for ranges. I'm still seeing some quirks though with the ReScript formatter, even after that - possibly related to / similar issue as: #2196 |
bryphe
added a commit
that referenced
this issue
Dec 12, 2020
…ion host
__Issue:__ Onivim 2 wasn't correctly handling ranges from the extension host that were created with `Number.MAX_VALUE` (or, any value with any exponent...). A `ParseFailedException("Expected null or:\n while decoding a list:\n element 0:\n in field \"range\":\n in field \"endColumn\":\n Expected an int, but got 1.7976931248623157e+308\n".` was being produced.
__Defect:__ Our JSON parsing was only handling integers
__Fix:__ Use the `float` JSON decoder, which does handle exponents, and cast to an `int` - handling overflows.
This fixes the parse failure, and allows for some basic formatting - but I'm still seeing some quirks with the ReScript formatter, when updating the buffer and running the formatter again.
Related #2820
bryphe
added a commit
that referenced
this issue
Mar 5, 2021
…its (#3233) __Issue:__ When running format providers, like `prettier` or `rescript`, after multiple iterations, there could start to be duplicated or corrupted text. __Defect:__ Some of the edits provided by the format provider, once they round-trip through our vim layer, weren't being applied back correctly in the extension host buffer updates (the `ModelContentChange` that we send to the extension host layer) - this would cause the buffer state to be de-sync'd - meaning that the view of the buffer text was different in the extension host than in the editor. The editor was correct, but the buffer text on the extension host side would have extra lines or extra concatenation, and when the next format was triggered, the formatting edits for the desync'd buffer would be applied, causing the issues in #2196 Currently, the way we send buffer updates is always linewise - and therefore a newline must always be included at the end. In the particular case of a formatting edit consolidating lines (deleting empty spaces), we wouldn't be adding that trailing newline - and this was the root cause of the desync. While investigating, I found another case with undo - creating multiple lines, and then undoing them, triggers a similar bug. __Fix:__ Simplify the way we decide to append a newline to correct these issues. Add a test case exercising the undo condition (once we have `$tryApplyEdit`, it'd be great to have that API exercised in a text synchronization case as well). In addition, add some extra tooling in our `oni-dev-extension` to support troubleshooting these issues - when running with `oni2 -f --silent --debug-exthost` and running the `Developer: Show buffer updates` command, the extension host's view of the buffer will be shown in the console after each update. __Next steps:__ - There's still a lot of room for improvement in the way we handle buffer updates - streamlining individual edits, and batched related updates into a single update call. Fixes #2196 and the remainder of #2820
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When attempting to format a ReScript file, Onivim fails to format the file and throws an error.
Steps to Reproduce
rescript-vscodeextension vsix file.:enew:w test.res:enewExpected Result
The ReScript file (
res) is formatted. No errors are displayed.Actual Result
The ReScript file (
res) is not formatted. Errors are displayed.The first format call produces:
Invalid range specified.The second format call produces:
ParseFailedException("Expected null or:\n while decoding a list:\n element 0:\n in field \"range\":\n in field \"endColumn\":\n Expected an int, but got 1.7976931248623157e+308\n".Environment
The text was updated successfully, but these errors were encountered: