fix: use StringView for @json.parse

[tonyfettes]

No description provided.

[coveralls]

Pull Request Test Coverage Report for Build 1284

Details

• 8 of 8 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.006%) to 89.615%

---

Totals
Change from base Build 1283:	0.006%
Covered Lines:	9302
Relevant Lines:	10380

---

💛 - Coveralls

[peter-jerry-ye-code-review]

Potential bounds checking issue in string operations

Category
Correctness
Code Snippet
buf.write_substring(
ctx.input.data(),
ctx.input.start_offset() + start,
end - start,
)
Recommendation
Add bounds validation before calling write_substring to ensure start_offset() + start doesn't exceed the underlying data bounds, or use a safer method like ctx.input.view(start_offset=start, end_offset=end).to_string()
Reasoning
The manual offset calculation could lead to out-of-bounds access if the StringView's start_offset and the local start don't align properly with the underlying data

Inconsistent StringView to String conversion pattern

Category
Maintainability
Code Snippet
return Number(n, repr.map(_.to_string()))
Recommendation
Consider creating a helper function for StringView to String conversion to centralize this logic, such as fn optional_stringview_to_string(sv: StringView?) -> String?
Reasoning
The pattern .map(_.to_string()) is repeated 4 times in the same file, creating maintenance overhead and potential for inconsistency

Unnecessary string conversion in number parsing

Category
Performance
Code Snippet
let s = ctx.input.view(start_offset=start, end_offset=end)
if !s.contains(".") && !s.contains("e") && !s.contains("E")
Recommendation
Perform character checking directly on the StringView without creating intermediate views, or cache the view creation if it's used multiple times
Reasoning
Creating a StringView for simple character existence checks may be less efficient than iterating through the original input directly, especially for short number strings