Implicit import check during target validation

[rylev]

Fixes #127

When performing target validation (i.e., whether a component graph represents a component that matches the given world), we were just iterating the explicit imports. Now, we iterate all imports both implicit and explicit.

This PR also contains a slight refactoring of encode_imports that isn't necessary but came from an early exploration and which I think makes the code more readable. Let me know if I should remove this.

When an implicit import is the cause of a validation error, the error message isn't wonderful since we don't have a span to point to like we do in the explicit import case. I think we can land this though before we figure out exactly how to improve the error message.

[fibonacci1729]

Thanks for digging into this! I haven't extensively studied the code just yet but I did try out the changes with the following example:

I have a component called spin:kv that targets:

world {
  import wasi:io/poll@0.2.0;
  import wasi:io/error@0.2.0;
  import wasi:io/streams@0.2.0;
  import wasi:http/types@0.2.0;
  import fermyon:spin/key-value@2.0.0;
  import wasi:cli/environment@0.2.0;
  import wasi:cli/exit@0.2.0;
  import wasi:cli/stdin@0.2.0;
  import wasi:cli/stdout@0.2.0;
  import wasi:cli/stderr@0.2.0;
  import wasi:clocks/wall-clock@0.2.0;
  import wasi:filesystem/types@0.2.0;
  import wasi:filesystem/preopens@0.2.0;
  import wasi:random/random@0.2.0;

  export wasi:http/incoming-handler@0.2.0;
}

And this wac script to do a targets check:

package test:test targets wasi:http/proxy@0.2.0;

export new spin:kv{...}...;

When running wac resolve script.wac I am getting the following error which I can't quite wrap my head around:

error: failed to resolve document

  × import `wasi:io/error@0.2.0` has a mismatched type for target world `wasi:http/proxy@0.2.0`
  ╰─▶ instance has unexpected instance export `wasi:http/incoming-handler@0.2.0`

Thanks again for tackling this; could you add a test or two when you get a chance?

[rylev]

@fibonacci1729 thanks for finding the issue! It turns out we were always assuming a 1 to 1 correspondence between an import node (i.e., a node in the wac graph) and the item we wanted to type check. However, implicit imports don't have nodes in the wac graph (that's what makes them implicit after all!). The latest change more directly provides the validate_target function with the item definitions it needs to check instead of it having to look up items by node id from the graph.

I think this should fix the issue you're seeing - in my testing I got errors that made much more sense and correctly identified where the component and the target world didn't line up.

I'll look into how we can add tests for this.

[rylev]

I looked into adding a test, and discovered a new issue I'd like to address first. The issue is that just like wac, wit sort of has a similar concept of implicit imports. If you use an item inside of an imported interface from another interface, that other interface will be implicitly imported. I'll need to do the work of looking up interfaces through used items as well as direct imports.

[rylev]

I've addressed the issue of interfaces implicitly imported through uses and the test I've added now passes. I believe this is ready for final review and merge.

[fibonacci1729]

Awesome work @rylev! I'll give this a review and test on monday.

[fibonacci1729]

Great work @rylev ! The code looks great (very understandable) and the manual tests i was running now pass.

From my example earlier, i now see:

× target world `wasi:http/proxy@0.2.0` does not have an import named `fermyon:spin/key-value@2.0.0`

... which is exactly how I expect it to fail.