Repository navigation
Conversation
|
Preview build of 4dea705: |
The hook leaves the error as it is when the link runs under a JavaScript frame or the statement is not found, so require() of an ES module, expect(import()).rejects and plugin text behave as on main. The locator parses a statement at a time and stops at the first match. It does not look in text that is already bundled, in the modules of an executable, or past the first mebibyte of the file. The change to the stack-string printer leaves this branch: #38308 and #38328 own it. WEBKIT_VERSION names the third preview build of oven-sh/WebKit#960, where a module namespace leaves out a name that does not resolve, so a stale `export { x } from` in a barrel cycle reports its own statement.
|
@Jarred-Sumner two decisions in this pair of PRs are yours. 1. Where the position comes from. On oven-sh/bun#7700 you sketched a 2. The AOT parity program. One more change here needs your eye: |
A link error is about one statement of the importing module: a named
import that the other module does not export, an ambiguous one, an
`export { x } from` that does not resolve. No code of that module runs
while it links, so the error has no frame there and does not say which
module holds the statement.
The eleven throws of the Bun arm of
CyclicModuleRecord::initializeEnvironment now go through
throwModuleLinkError. It calls Bun__locateModuleLinkError with the
importing record, the error, the kind of statement and the name that
identifies it: the local name of an import, the exported name of an
indirect export. The host finds the statement in the source the user
wrote and gives the error its location. JavaScriptCore cannot do that
when the host transpiles, because the text it holds is not that source.
The default definition is weak and does nothing, so `jsc` throws the
same errors as before. ImportEntry and ExportEntry do not change, and a
link that succeeds runs the same code.
The helper has a second form that takes the message and makes the SyntaxError itself, so an arm that built a message still makes one call. linkImportEntry takes the importing record from the module environment it already holds. The lambda captures nothing more than before, so a link that succeeds stores nothing more either.
In a cycle, the namespace of a module can be asked for before the module
that has `export { name } from` is linked. The four arms of
getModuleNamespace then threw `Exported binding name 'name' is not
found.`, which names no module and no statement.
GetModuleNamespace leaves such a name out (step 3.c of the
specification). The module that has the statement throws when it is
linked, through throwModuleLinkError, so the host can say where the
statement is.
The host's function is now declared in CyclicModuleRecord.h, and the
compiler checks the host's definition against it.
3063046 to
3adbc9f
Compare
The arms of CyclicModuleRecord::initializeEnvironment that throw a link error built the message in place. Two of them also asked ResolveExport a second time, for the "Did you mean" text. All of that was code of the function that links every module, and the values it needed were kept in registers and stack slots of that function. throwIndirectExportLinkError and throwImportLinkError now build the error from what the arm already holds: the entry, the other module and the kind of resolution. Each arm is one call. The messages do not change.
Part of oven-sh/bun#5582.
Problem
SyntaxError: Export named 'a' not found in module '/repro/dep.ts'.CyclicModuleRecord::initializeEnvironmentthrows it while no code of the importing module runs, so the error has no frame there.getModuleNamespacethrowsExported binding name 'x' is not found.for a staleexport { x } from.Fix
initializeEnvironmentgo throughthrowImportLinkErrorandthrowIndirectExportLinkError. They build the same errors and callBun__locateModuleLinkErrorwith the importing record, the error and the name that identifies the statement.CyclicModuleRecord.hdeclares that function. The definition here is weak and does nothing, sojscthrows the same errors. Bun defines it in Locate the failing import of a module link error in the source of the importer bun#47531.getModuleNamespaceleave the name out, as the specification's GetModuleNamespace does. The module that has the statement then throws from its own link.Background
ImportEntryand wrote the location twice. HereImportEntryandExportEntrydo not change.Downsides
getModuleNamespacenow links when the module that has the statement is TypeScript: a TypeScript record already skips a re-export that is not found.Notes
A link that succeeds (
gdb, onenextiat a time, release builds of Bun at 9e76acc6f, Linux x64)initializeEnvironmentwith its calls oflinkImportEntryexecutes 221, 446 and 356 instructions for the three module records of a two-module program before, and 226, 446 and 361 after.initializeEnvironmentis 8,094 bytes before and 6,974 after.linkImportEntryis 1,335 and 787.getModuleNamespaceis 10,336 and 9,671. The two new functions are 1,261 and 683 bytes.Other facts
ErrorInstance::setErrorInfoForEmbedderError. JavaScriptCore writes nothing on the error.