Closed lukewagner closed 9 months ago
To confirm, these two binary rules:
importdecl ::= in:<importname> ed:<externdesc> => (import in ed)
exportdecl ::= en:<exportname> ed:<externdesc> => (export en ed)
should change to refer to importname'
and exportname'
, right?
One other piece of feedback from https://github.com/bytecodealliance/wasm-tools/pull/1262, an implementation of this (and a few other PRs to the component model). Currently URLs are defined as "stuff that doesn't contain <
or >
", but integrity-metadata
is defined with the w3c definition. It might make sense to do the same thing in both situations? Either require both are w3c-defined valid or both are something-nonempty-someone-else-parses-this.
I'll admit though I know nothing about integrity-metadata
in w3c, if it's a simple format that's easy to parse then may as well "just" do that too.
@alexcrichton That's a good question and I was wondering about the same options for the same reason. Looking at the EBNF of integrity-metadata
(here) and recursing through all the definitions, it does seem like integrity-metadata
is much much simpler than a URL, but a good deal more complicated than, say, an interfacename
, so it's in a sortof grey area where I could go either way.
But another reason in favor of having the Component Model fully parse integrity-metadata
is that, unlike URLs, which are pretty universal (ignoring the many awful edge cases), there are, I believe, a couple of different hash text formats out there. E.g., OCI uses something different. Thus, it seems quite possible that different parts of the ecosystem might end up adopting slightly-different hash formats (accidentally or intentionally) if the common validation rules baked into the core-est tooling don't fix one.
Ok makes sense to me! I'll dig in and implement that
Awesome, thanks to you and Alex for the feedback. I'll merge now since there don't seem to be any open issues and we can file follow-up issues if needed as usual.
This PR fleshes out the idea in #253 to move the structured information of imports/exports into the import/export name string, maintaining the same validation structure, but now inside a single quoted strong. The motivation for this change is to have a simple canonical string for all import/export names that contains all the structured information, without requiring host and toolchain implementations to define their own ad hoc string-serialization conventions. The rationale here is basically the same as the earlier design choice to put method/constructor/etc annotations inside the name strings, with the net effect of making the way externally-meaningful name information is represented in components somewhat more regular.
Some specific details:
(interface ...)
imports.<name>
refer to the kebab-name case. Moreover,<name>
wasn't really a "kebab-name" anyway, since it also contains method/constructor/static annotations (with embedded square brackets and periods). Thus, this PR proposes to rename this production to<plainname>
, attempting to distinguish plain names from all the other kinds of names that carry more semantic information, but happy to hear other thoughts on how to call this.Copying from this PR, an example showing the new import/export names is: