Parents: #473, #472 Related: #666, #675
Problem
Four owned string result builders still append the physical bytes returned by toStringV into canonical WTF-8 output buffers:
String.rawsubstitutions;Array.prototype.toLocaleStringelement results;%TypedArray%.prototype.joinseparators and rendered elements;%TypedArray%.prototype.toLocaleStringelement results.
These paths are byte-identical while flat Latin-1 storage is disabled. With physical flat storage active, a non-ASCII Latin-1 String result can be copied as invalid canonical StringData, corrupting the observable output and any later UTF-16 operation.
Scope
- Route only these direct concatenating
ToStringconsumers through the representation-aware WTF-8 helper. - Preserve exact coercion count and order, abrupt completion, separator behavior, resize/detach behavior, forwarded locale arguments, output allocation ownership, and OOM propagation.
- Keep ASCII and canonical StringData borrowed without extra conversion.
- Cover primitive and object-returned non-ASCII text under canonical and physical flat-Latin-1 storage.
No-workaround rules
- No flat-storage disablement, eager global canonicalization, replacement characters, duplicate coercion, hidden second pass, Test262 exclusion, or third-party string builder.
- No stack, queue, job, Promise, Worker, or Map/Set iterator changes.
Acceptance
- Every affected result builder appends canonical semantic WTF-8.
- Each custom
toStringortoLocaleStringhook runs exactly once and in specification order. - String.raw, Array locale output, TypedArray join, and TypedArray locale output preserve exact non-ASCII text.
- The witness passes with canonical storage and with
flat_storage_activeenabled, then the switch is restored and not landed. - Relevant nonzero Test262 accounting, focused Debug/ReleaseSafe/TSan, and full units pass with exact flips reported.