`ecmarkup --lint-spec --strict` did not catch an undeclared alias in ECMA-262 Annex B

[gibson042]

tc39/ecma262@42d84f2#r3656289857

I accidentally removed the Let _size_ be the length of _string_. step from String.prototype.substr, but ecmarkup did not complain about later steps referencing the missing alias.

[bakkot]

Some lint rules, including this one are skipped for Annex B because it does things in a weird way that makes them hard to lint.

[michaelficarra]

Is that still true though? We've done a bit of refactoring of how Annex B modifies algorithms recently, so we may be able to enable some of these skipped rules.

[bakkot]

It is still true at least for some augmented SDOs like CompileAtom, which references an argument only declared where the SDO is originally declared.

[jmdyck]

Re Annex B CompileAtom, the preamble mentions _direction_, so it should also mention _regexpRecord_. (I should have done that in tc39/ecma262#2716)

Similar re Annex B CompileToCharSet.

Those might be the only two. Can ecmarkup get the parameter names from the preamble, or does it need a structured header?

[bakkot]

The "Initializers in ForIn Statement Heads" section also has a few labelSets and an iterationSet.

Can ecmarkup get the parameter names from the preamble, or does it need a structured header?

It assumes any variable name referred to in the header or preamble is available for use in the algorithm body. This is too conservative in many cases but avoids false positives.

[gibson042]

The changes turned out to be minimal—just parameter names for CompileAtom/CompileToCharSet/ContainsDuplicateLabels/ContainsUndefinedContinueTarget and alias redeclaration in Date.prototype.setYear.

tc39/ecma262#3932