Open alexcrichton opened 1 year ago
Nice writeup and analysis! I think you're right that we should reject that world. What took me a sec was how to precisely state the criteria/rationale for rejection. I think it might be this: if we say that the semantics of a Wit interface is a component type that represents use
s as import
s, then the component type derived from the final anonymous inline interface
in your example would have to be:
(type $anonymous_interface (component
(import (interface "foo:bar/a") (instance $a (export "name" (type (sub resource)))))
(alias export $a "name" (type $name))
(import (interface "foo:bar/b") (instance $b (export "name" (type (eq $name)))))
(alias export $b "name" (type $name2))
(export "name" (instance
(export "name" (type (eq $name)))
(export "name2" (type (eq $name2)))
))
))
(Attempting to import foo:bar/a
twice would violate unique naming.) Thus, it is the eq
constraint inside foo:bar/b
that requires clients of this anonymous interface (viz. world w
) to supply a single type for foo:bar/a.name
. There is, technically, a valid way to satisfy this constraint--to have both the use a.{name}
and use b.{name as name2}
satisfied by a single injected import of foo:bar/a
--but that seems very surprising and probably not what anyone wants, so that's why we reject and require you to use the (future TBD) power syntax to resolve.
Yeah that sounds right to me, and it's actually what the fuzzer ended up catching. Part of the creation of a component using resources implicitly assumed that two imports of a resource were the same (they had an eq
bound) but then two resources were passed in because the two resources came from two different instances which then caused issues along the lines of "expected this to validate but it didn't".
In any case https://github.com/bytecodealliance/wasm-tools/pull/1081 implements the idea here to reject more worlds.
One of the subtelties of imports and exports in WIT is that they both need to somehow resolve their transitive dependencies. For example this world:
the
bar
import transitively depends onfoo
for type information (trivially in this case but it could be more complicated too, or "significant" with resources). For the import case this is resolved by injecting more dependencies, as is evidence by runningwasm-tools component wit
over the above, printing:Despite not being written explicitly the
import foo
statement was injected automatically. More broadly all transitive dependencies of imports are injected as further imports. This works well for now and probably is the right thing to do, but the tricky part is with exports. Instead if the above world is:(note the change of
import
toexport
then what to do here is less clear. For now what happens is that the transitive dependencies are sometimes still injected as imports:If, however, the world were subtly different a different resolution is applied. If the world explicitly lists both interfaces as
export
-edthen no imports are injected. Instead it's assumed that
bar
's dependency onfoo
is satisfied by the exported interfacefoo
. More generally the algorithm here is roughly that dependencies of exports are walked and if they don't exist as an export then all futher transitive dependencies are added as imports. If the export already exists then it's assumed that's already taken care of its dependencies, so it's skipped.This strategy was intended to be a reasonable default for the time being where in the future "power user" syntax (or something like that) could be added to configure more advanced scenarios (e.g. changing these heuristics). In fuzzing resources, however, I've found that this doesn't actually work. Consider for example this world:
here the
name
kebab import depends on botha
andb
. It's also the case thatb
depends ona
. Given the above heuristics though what's happening is:name
's dependency ona
is satisfied byexport a
name
's dependency onb
is satisfied by an injectedimport b
, which in turn injects animport a
This means that
name
actually can access two different copies ofresource name
, one from the import and one from the export. This not only causes problems (hence the fuzz bug) but additionally I think isn't the desired semantics/behavior in WIT. For example ifb
defined some aggregate type that containeda
's resource then thename
export should be able to use the aggregate and the resource froma
and have them work together. Given the current lowering, though, that's not possible since they're actually different copies.Ok that's the problem statement (roughly at least). The question for me now is how to fix it? Some hard requirements that must be satisfied are, in my opinion:
One alternative I can think of is that all transitive dependencies of exports are forced to be imports. This means that it will change the meaning of a few examples I listed above. Additionally the
world w
in question here would rightfully have two copies ofa
's resource, one imported and used byexport name
and one defined locally and exported (used byexport a
). The downside of this though is that there's no means by which a resource can be defined locally and used by another export.Another alternative is to make the above
world w
simply invalid. There are two "paths" to thea
interface where one is imported and one is exported, so it's an invalid world as a result. The fix would be to addexport b
to the list of exports which means thatexport name
would use both exports.I'm curious though if others have thoughts on this? I realize I could be missing something obvious by accident or something like that! As I type this all out though I'm realizing the "simply say
world w
is invalid" is probably the way to go since it doesn't close off some more interesting use cases while still making this reasonable to work with today.