fix/json unicode offsets

[jurgenvinju]

Fixes unicode offsets for the JSON parser/validator:

• parse error locations
• origin src keyword fields
• fully satisfies the loc semantics of vallang and Rascal (offset, length, line, column)

This makes JSON parsers ready for use in an editor/UI context. From that perspective, this was a bug. From the "we had a reasonable JSON parser" perspective, this was an enhancement.

Instruments the OriginTrackingReader embedded in JSONValueReader to accurately deal with the presence of unicode surrogate pairs in the char buffer of the reader.

Note that unicode characters in comments are equally responsible for shifts in the offsets as unicode characters in string constants and field names.

• start of buffer offset compensated for presence of surrogate pairs
• pos index into buffer compensated for surrogate pairs
• column position (same)
• line position (same)
• asserts added to reflect the many many assumptions the links between GsonReader, OriginTrackingReader and JSONValueReader depend on.
• comments to explain the above as well; it's rather finicky
• added specific file with unicode for testing purposes
• added JSON generators with different shapes of unicode to the JSONIOTests, specifically for triggering exceptional conditions around the buffer limits:
  • high surrogate and low surrogate before the limit
  • high surrogate before the limit and low surrogate after the limit
  • several surrogate pairs in a row around the limit
  • alternated surrogate pairs and normal chars around the limit

The current solution still streams quickly and scales freely to very long JSON content, very long lines in JSON content, and very long comments or strings in JSON content.

[codecov]

Codecov Report

❌ Patch coverage is 85.24590% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 46%. Comparing base (827298e) to head (43aeda6).

Files with missing lines	Patch %	Lines
...pl/library/lang/json/internal/JsonValueReader.java	85%	2 Missing and 7 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##              main   #2659   +/-   ##
=======================================
  Coverage       46%     46%           
- Complexity    6721    6724    +3     
=======================================
  Files          794     794           
  Lines        65912   65954   +42     
  Branches      9888    9903   +15     
=======================================
+ Hits         30824   30870   +46     
+ Misses       32698   32690    -8     
- Partials      2390    2394    +4     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[DavyLandman]

Error: RROR] /home/runner/actions-runner/_work/rascal/rascal/src/org/rascalmpl/library/lang/json/internal/JsonValueReader.java:[1032,17] cannot find symbol
  symbol: variable lineHandler
Error: RROR] /home/runner/actions-runner/_work/rascal/rascal/src/org/rascalmpl/library/lang/json/internal/JsonValueReader.java:[1033,17] cannot find symbol

I think there's some uncommitted file?

[jurgenvinju]

Yes, there was an uncommitted file. Thanks

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[DavyLandman]

I think this looks good, but I have the feeling it's duplicating code we already have in the ColumnOffset code. I suspect we'll be able to reduce the size of this PR (and thus new code to maintain) if we can reuse that.

[DavyLandman]

this would mean that a broken pair causes offsets? is that fine?

[DavyLandman]

a lot of this code reminds me of the ColumnMaps and LineColumnOffsetMap (and its implementation ArrayLineOffsetMap). They've been migrated to rascal a while back, so maybe we can reuse that code here?

Perhaps the LineColumnOffsetMap needs to learn a few new features, but it has been used for quite a few years in rascal-lsp for a very similar job.