ParseScript: sourceText parameter type inconsistency with ParseText

[alexey-alanreys]

ParseScript (§16.1.5) declares sourceText as ECMAScript source text,
which per §11.1 is a sequence of Unicode code points.

However, ParseText (§11.1.6), which ParseScript calls directly in step 1,
accepts sourceText as a String or a sequence of Unicode code points and
explicitly handles the String case via StringToCodePoints.

This means callers like the HTML spec can pass a String to ParseScript,
which works in practice but violates the declared type at the ParseScript level.

Suggestion: update ParseScript's parameter type to
a String or a sequence of Unicode code points to match ParseText's actual accepted input.

[nicolo-ribaudo]

This is where HTML passes a string to ParseScript: https://html.spec.whatwg.org/#creating-a-classic-script

[alexey-alanreys]

Yes, that's exactly the case I'm referring to. In that algorithm, source
is a JavaScript string (as per the HTML spec's string type), which is then
passed to ParseScript — whose declared parameter type is ECMAScript source text
(a sequence of Unicode code points per §11.1), not a String.

The mismatch is resolved implicitly by ParseText step 1 (StringToCodePoints),
but it's not reflected in ParseScript's own type declaration.

[alexey-alanreys]

The same inconsistency exists in ParseModule (§16.2.1.7.1), which also declares
sourceText as ECMAScript source text but is called with a String by the HTML spec
in the "create a JavaScript module script" algorithm:

Let result be ParseModule(source, settings's realm, script).

where source is explicitly typed as a String.

[linusg]

Leaving this open as Richard made a linked PR but please note https://github.com/tc39/how-we-work/blob/main/AI_POLICY.md. Pasting LLM output for us to read is not appreciated.