BUG: Module exporting undeclared name should be a syntax error

Another bug I found whilst working on #5759 though I do not currently have a fix planned for this.

Per https://tc39.github.io/ecma262/#sec-module-semantics-static-semantics-early-errors It is a Syntax Error if any element of the ExportedBindings of ModuleItemList does not also occur in either the VarDeclaredNames of ModuleItemList, or the LexicallyDeclaredNames of ModuleItemList.

POC:

//start.js
import {Fun} from "./other.js";
print(Fun);

//other.js
export {anything as Fun};

Note the same repros if instead of “anything” you use any other undeclared name OR use a global like Number or Array or if you don’t alias “anything”.

Output with ch: undefined, jsc and v8 throw Syntax Errors (Can’t do an eshost repro at the moment as eshost doesn’t yet interact with ch’s module flag)

This causes numerous test262 failures.

[boingoing]

Seems like something we should be able to do at name binding. We do push a pidref to ‘anything’ when we export it, right? When we bind names, we could throw a SyntaxError if we find a referenced name with no declaration.

[pleath]

You’re right, no pid ref is pushed in this case. It looks like we implemented it without attempting to bind the exported name to a declaration. Either we missed this requirement in the spec or implemented an earlier spec that didn’t contain the requirement.

What you’ll want to do is call PushPidRef from Parser::AddModuleImportOrExportEntry, passing in the IdentPtr of the local name, and store the resulting PidRefStack* on the export record. Binding will fill in the Symbol* on the PidRefStack. When we later resolve the export entries, a null Symbol* will indicate an undeclared name. Note that this has to be done whether buildAST is false or true, so the caller of AddModuleImportOrExportEntry will have to make the call in both cases.

Does all that make sense?