Interop: a read-only host collection refuses script with a JavaScript error, not the CLR's own (backport of #3385)

[lahma]

Backport of #3385 (10b0955dc on main), which fixes #3382.

The observable change, stated plainly

This changes the exception type an embedder sees. Script that asks a read-only host collection to
change used to raise the CLR's System.NotSupportedException out of Engine.Evaluate; it now raises a
TypeError — in strict mode, or silently refuses in sloppy mode, depending on the operation. An embedder
whose code reads

try { engine.Evaluate(script); }
catch (NotSupportedException) { /* the script tried to write my read-only list */ }

will no longer see that exception, and one that has a bare catch (JavaScriptException) will start seeing
a refusal it never saw before. A catch (Exception) is unaffected.

It qualifies as a correctness fix rather than a feature all the same, for two reasons that are worth
separating. It is spec-required: push, pop, splice, sort and reverse are specified in terms
of Set(O, k, v, true) and DeletePropertyOrThrow, which raise a TypeError on a false [[Set]], and a
bare assignment is an ordinary [[Set]] returning false. And the exception it replaces was not
catchable from script at all — neither a script try/catch nor a host catch (JavaScriptException)
could see it — so the behaviour being changed is one no script could handle and one whose only host-side
handler was a catch on a CLR type the engine never promised to raise. The maintainer should judge that
trade; it is the only behavioural change in the PR.

Before, on unmodified 4.x

Jint.Tests.PublicInterface/HostReadOnlyCollectionTests.cs was added to this branch on its own, with no
engine change, and run on both target frameworks. Six read-only shapes × ten operations × both modes, plus
the growable control, the message, and the ArraySegment<T> reclassification:

Target framework	Failed	Passed	Total
net10.0	52	16	68
net472	52	16	68

Every one of the 52 is a System.NotSupportedException escaping Engine.Evaluate — there is not a single
other failure shape in the list. Two representative ones:

Failed …AnArrayGenericThatMustGrowAReadOnlyCollectionThrowsACatchableTypeError(shape: "ReadOnlyCollection", operation: "host.push(4)")
 System.NotSupportedException : Collection is read-only.
   at Jint.Runtime.Interop.ArrayLikeWrapper.SetAt(Int32 index, JsValue value)
   at Jint.Native.Array.ArrayPrototype.Push(JsValue thisObject, ReadOnlySpan`1 arguments)
   …
   at Jint.Engine.Evaluate(String code, String source)

Failed …TheRefusalIsTheOrdinaryReadOnlyPropertyTypeError(shape: "ImmutableList")
 System.NotSupportedException : Specified method is not supported.
   at Jint.Runtime.Throw.NotSupportedException(String message)
   at Jint.Runtime.Interop.ArrayLikeWrapper.SetAt(Int32 index, JsValue value)

The 16 that pass are the assignments ReadOnlyCollection<T>'s get-only indexer already refused by
accident, and the IReadOnlyList<T> length writes CanWrite => false already refused.

main measured 49/19 on the same file. The three extra failures here are ArrayList.ReadOnly's length
writes and delete, which on main are refused by #3381's ListWrapper.IsFixedSize — a PR that is not on
this branch and is not needed for this one.

After

Target framework	Failed	Passed	Total
net10.0	0	68	68
net472	0	68	68

The TypeError an embedder actually reads is the ordinary one — Cannot assign to read only property '3'
of object '#<Object>' — because the refusal now happens in [[Set]], before the collection is
reached at all. Nothing invents an interop-specific message.

What changed

One fact taken from the target, and three call sites:

• ArrayLikeWrapper gains IsReadOnly; CanWrite becomes AllowWrite && !IsReadOnly and stops being
  virtual. ReadOnlyListWrapper<T>'s CanWrite => false override becomes IsReadOnly => true, which is
  the same statement about element writes plus the one it was missing about the length.
• ListWrapper reads IList.IsReadOnly; GenericListWrapper<T> reads ICollection<T>.IsReadOnly.
• The three lanes that consulted Options.Interop.AllowWrite directly rather than through CanWrite
  now consult CanWrite: ArrayLikeWrapper.Delete, ArrayLikeWrapper.SetAt, and ArrayOperations'
  ArrayLikeOperations.Set. Those three are precisely what made the mutators reachable for a read-only
  target.
• Because of that the mutators are now unreachable for a read-only wrapper. Their bodies still refuse —
  ThrowReadOnly() instead of Throw.NotSupportedException() — as a documented backstop, so a lane added
  later cannot re-open the same hole.

The one carve-out

ICollection<T>.IsReadOnly cannot be taken at face value. System.Array and ArraySegment<T> both report
true through it to mean cannot grow, and both accept element writes — the non-generic IList asks
IsReadOnly and IsFixedSize separately and the generic interface collapsed them into one flag.
GenericListWrapper<T> therefore treats a T[] or an ArraySegment<T> target as fixed-size and
everything else's declaration as the truth. That reclassifies ArraySegment<T>, which is the point rather
than a side effect: it leaked NotSupportedException from push/pop/splice/a length write and
ArgumentOutOfRangeException from a write past the end, and now answers exactly as an int[] live view
does while keeping host[0] = 9.

Two adaptations this branch needed, and one thing left out

4.x's interop has diverged from main, so two hunks are not literal copies:

1. ThrowFixedSize moves up from ArrayWrapper<T> (where it was private) to ArrayLikeWrapper (as
   protected), unchanged in message and behaviour, because the shared ThrowIfLengthCannotChange guard
   needs it. On main Native AOT: a degraded array view still refuses a resize, and the value-type generic sites are eight, not five #3381 had already hoisted it.
2. The integral-index refusal in ArrayLikeWrapper.Set drops its numValue < Length bound, which is
   how the line already reads on main — it lost the bound in Disable projected CLR writes by default #3054 (Disable projected CLR writes by
   default), a v5 change that is not on this branch. Without that removal a read-only target's growth
   write — which is exactly what push is — still fell through to the reflected indexer, so
   push/host[3] = 9 continued to leak NotSupportedException for the two shapes whose indexer setter
   throws rather than being get-only: a host IList<T> that declares IsReadOnly, and
   ArrayList.ReadOnly. Measured: with the rest of the port in place and this bound still present, 6 of
   the 68 cases still failed, all six with System.NotSupportedException : Collection is read-only.
   Removing it changes nothing else on this branch, because ObjectWrapper.Set already refuses when
   Interop.AllowWrite is off (!accessor.Writable || !AllowWrite) and when the wrapper is not extensible.

Deliberately not folded in: anything from the host-collection index cluster (#3356, #3416, #3464,
#3472, #3480, #3425). None of it is required here — the one line above predates #3416 and comes from #3054
instead — and it is being evaluated separately as a unit. #3381 is not needed either.

Also unchanged, exactly as on main: a growable List<int> still refuses list[3] = 9 with a raw
ArgumentOutOfRangeException while list.length = 5 grows it. Same defect class, different cause, out of
scope.

Verification

• dotnet build -c Release — 0 errors. The one MSBuild warning (MSB3277, a package assembly-version
  conflict in Jint.Tests.CommonScripts' net472 leg) is pre-existing and unrelated.
• Jint.Tests — 6,958 passed on net10.0, 6,873 on net472, 0 failed.
• Jint.Tests.PublicInterface — 1,570 passed on net10.0, 1,563 on net472, 0 failed. The public API
  baselines did not move: CanWrite, IsReadOnly and the two refusals are all members of internal types.
• Jint.Tests.CommonScripts — 28 passed on each of net10.0 and net472, 0 failed.
• Jint.Tests.SourceGenerators — 52 passed, 0 failed.
• Both suites again with JINT_HOST_CONTRACT_VERIFICATION=1 — 0 failed on both target frameworks.
• Jint.Tests.Test262 — 102,499 passed, 0 failed, 185 skipped of 102,684, matching this branch's control
  exactly. The full run lost intl402/supportedLocalesOf-unicode-extensions-ignored.js in both modes to
  load on this shared machine (31 s each, against a 30 s engine default); the two pass in 2 s in isolation.
• No benchmark: the read path (Get/GetJsValueAt) is untouched, and the write path trades one virtual
  CanWrite call for one virtual IsReadOnly call. Wrapping a host IList/IList<T> now reads one extra
  interface property once, at construction.

🤖 Generated with Claude Code

https://claude.ai/code/session_014W5mbjGhyvgAS4pivXoc4S