fix(string): add maximum length limit to JsString to prevent OOM crashes

[abhinavs1920]

This Pull Request fixes/closes #4409 .

It changes the following:

• Added MAX_STRING_LENGTH constant in the string crate.
• Made the main concatenation paths (JsString::concat and concat_array) fallible and check the limit before attempting allocation.
• Updated the + operator fast path and ConcatToString opcode to properly propagate the RangeError.
• Updated String.prototype.concat accordingly.

Why this approach

• Matches the behavior of V8, SpiderMonkey, and JavaScriptCore.
• Prevents the crash while preserving all existing behavior for strings below the limit.
• Uses Boa's standard JsResult + ? error handling patterns.

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	52,963	52,963	0
Passed	50,732	50,732	0
Ignored	1,426	1,426	0
Failed	805	805	0
Panics	0	0	0
Conformance	95.79%	95.79%	0.00%

Tested main commit: f075094f9674f9919b4d2e85ca1bcba410bf34b0
Tested PR commit: 58dec123961fd75590d99977a58dc74841faa074
Compare commits: f075094...58dec12

[abhinavs1920]

Heyy @jedel1043 @nekevss @!
While working on the fix, I noticed a pattern repeated a bit over the codebase....

.map_err(|_| JsNativeError::range().with_message("Invalid string length"))?

This shows up in multiple places around string concatenation, and similar JsNativeError::range().with_message(...) patterns appear.

For now, I’ve kept it as-is to stay consistent with the current style. But I was thinking, has there been any discussion around introducing a small helper (or trait) to reduce this kind of boilerplate?

Something like:

• a helper function for common errors, or
• an extension method on Result

Totally understand if the verbosity is intentional for clarity, just wanted to check if this is something worth exploring further as a follow-up.

Thanks :)

[codecov]

Codecov Report

❌ Patch coverage is 81.81818% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.63%. Comparing base (6ddc2b4) to head (58dec12).
⚠️ Report is 921 commits behind head on main.

Files with missing lines	Patch %	Lines
core/string/src/lib.rs	62.50%	3 Missing ⚠️
core/engine/src/value/operations.rs	87.50%	2 Missing ⚠️
core/engine/src/vm/opcode/concat/mod.rs	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #5277       +/-   ##
===========================================
+ Coverage   47.24%   59.63%   +12.39%     
===========================================
  Files         476      589      +113     
  Lines       46892    63494    +16602     
===========================================
+ Hits        22154    37865    +15711     
- Misses      24738    25629      +891     

☔ 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.

[zhuzhu81998]

For now, I’ve kept it as-is to stay consistent with the current style. But I was thinking, has there been any discussion around introducing a small helper (or trait) to reduce this kind of boilerplate?

there kinda is but its not a lot better. see

boa/core/runtime/src/url.rs

Line 70 in cd1a386

.map_err(|e| js_error!(TypeError: "Failed to parse base URL: {}", e))?;

[zhuzhu81998]

Made the main concatenation paths (JsString::concat and concat_array) fallible and check the limit before attempting allocation.

I thought there were other places where a new JsString can be created.