Editorial: Introduce IsStrict() abstract operation

[jmdyck]

I've broken it out into 6 5 commits in case that helps review.

---

commit 1:

Rename the existing SDO "IsStrict" to "ScriptIsStrict", because it's specific to Scripts, and I want the general name for the general operation.

---

commit 2:

The algorithms in the spec have 7 occurrences of:

X is contained in strict mode code

and 22 occurrences of:

X is strict mode code

This commit changes all of the former to the latter.

It isn't obvious whether or not this is a trivial change.

At first, I thought it was non-trivial, with the following reasoning: Clearly, you can have islands of strict mode code (SMC) within a sea of non-SMC. So, for such an island, it seems like it is SMC, but it's not contained in SMC, it's contained in non-SMC. (And so, this commit's change might cause the conditions to admit cases they currently don't, when X is SMC but isn't contained in SMC.)

However, consider test262's language/statements/function/name-eval-strict-body.js, which is basically:

/*---
negative
  phase: parse
  type: SyntaxError
flags: [noStrict]
---*/
$DONOTEVALUATE();
function eval() { 'use strict'; }

which throws a SyntaxError because (roughly speaking) 'eval' isn't allowed as the name of a strict mode function.

In more detail:

• The [noStrict] means that the global code is non-SMC.

• The 'use strict' means that the source text matched by:

  • the FunctionBody,
  • the (empty) FormalParameters, and
  • the BindingIdentifier

  are all SMC.

• The relevant early error rule is from 13.1.1 Static Semantics: Early Errors, for BindingIdentifier : Identifier:

It is a Syntax Error if the source text matched by this production is contained in strict mode code and the StringValue of |Identifier| is either "arguments" or "eval".

So in order for this error to apply, we must conclude that the source text matched by BindingIdentifier is contained in SMC. We can readily agree that it is SMC, but "contained in" is trickier: is eval contained in eval? Or maybe the idea is that eval is part of all the SMC associated with the function decl.

Anyhow, it seems like, as far as the spec is concerned, "is contained in SMC" means the same as "is SMC",

---

commit #3:

Normally, we say "the source text matched by X is strict mode code", but 3 spots leave out "the source text matched by". I think that's just a mistake, so this commit inserts the missing text.

---

commit #4:

With the relevant pseudocode mostly consistified, introduce the IsStrict() abstract operation.

---

commit #5:

Change:

If IsStrict(X) is *true*, let _strict_ be *true*; else let _strict_ be *false*.

to just:

Let _strict_ be IsStrict(X).

---

commit #6: [Dropped Oct 28]

IsStrict(this production)
sounds odd, like it's asking whether a production is strict. So this commit changes such usages to
IsStrict(this |Foo|)
where possible (i.e., when the associated productions have only one LHS symbol), and to
IsStrict(this phrase)
otherwise.

[michaelficarra]

I like this mainly for having a good way to find the locations where strict mode code is being tested. This should establish the editorial convention that we use IsStrict wherever applicable. This should also establish the editorial convention that we refer to a production by the LHS nonterminal in the SDO steps when the SDO is defined over a single production (or productions all sharing a LHS).

[jmdyck]

force-pushed to drop the last commit, as it's been superseded by PR #3210.