wasmtime / PR #10259 feat(wasmtime): add error hint for m... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #10259 feat(wasmtime): add error hint for m...

Wasmtime GitHub notifications bot (Feb 20 2025 at 18:45):

vados-cosmonic opened PR #10259 from vados-cosmonic:feat(wasmtime)=add-error-hint-for-missing-wasi-flags to bytecodealliance:main:

This commit adds some code to print an error hint when a failed wasmtime run command could have been called with arguments (in particular -S <capability>) that would have enabled the command to succeed.

Output looks like this, when running a module that imports wasi:http:
warning: missing import [wasi:http/types@0.2.2] has a WASI import option [http]  that has not been enabled -- consider re-running with '-S http'.
Run `wasmtime -S help` for a full list of WASI import options.

Error: failed to run main module `http_hello_world.wasm`

Caused by:
    0: component imports instance `wasi:http/types@0.2.2`, but a matching implementation was not found in the linker
    1: instance export `fields` has the wrong type
There are a few bits left to figure out (ex. seems like wit-parser doesn't yet have any shared/reusable relatively simple function for parsing import names into constituent parts?), but wanted to put up a draft to get some feedback, and make sure this is even desirable for maintainers.

Wasmtime GitHub notifications bot (Feb 20 2025 at 18:55):

vados-cosmonic updated PR #10259.

Wasmtime GitHub notifications bot (Feb 21 2025 at 18:08):

alexcrichton commented on PR #10259:

Personally I'm always a fan of improving error messages, so overall seems like a good idea.

For the specifics though I'd prefer to try to get more structured data here as opposed to having stringly-typed error messages with string searching for when to print an error. For example we could add a dedicated error type which indicates exactly which import was not found (e.g. ComponentImportNotFound or something like that) to extract the missing one. Matching that to a WASI interface, and then to a flag, is going to be a bit trickier and that's where some more "stringly-typed" things may need to come into play (or just rough heuristics).

Using wit-parser here I'll note that the dependency doesn't already exist at runtime. There's additionally not WIT embedded in the CLI itself. In theory the generate! macro could generate extra structures to detect "is this import supplied by this" but then that also runs into version numbers and matching and such.

Basically I think it'll be unfortunately pretty nontrivial to present a good error message here, so to improve things it's probably necessary to accept false positives/negatives for the time being.

Wasmtime GitHub notifications bot (Feb 22 2025 at 00:46):

vados-cosmonic commented on PR #10259:

For the specifics though I'd prefer to try to get more structured data here as opposed to having stringly-typed error messages with string searching for when to print an error. For example we could add a dedicated error type which indicates exactly which import was not found (e.g. ComponentImportNotFound or something like that) to extract the missing one. Matching that to a WASI interface, and then to a flag, is going to be a bit trickier and that's where some more "stringly-typed" things may need to come into play (or just rough heuristics).

Yeah I definitely agree that it'd be better to have a structured error here -- given that we don't yet have a unified way to parse/represent the text of an import name (AFAIK, outside a Resolve), I figured that might be a bit difficult to get perfectly (we might end up passing a string anyway as the import name?).

Basically I think it'll be unfortunately pretty nontrivial to present a good error message here, so to improve things it's probably necessary to accept false positives/negatives for the time being.

Yeah what do you think would be a good way to proceed here? To just print the message regardless of error contents, maybe as a general hint ?

Wasmtime GitHub notifications bot (Feb 24 2025 at 22:14):

alexcrichton commented on PR #10259:

A possible idea:

Add a dedicated type to wasmtime::component::Linker where the error type represents "this failed to link because some import was missing" or something like that.

The CLI detects this case and then falls back to something to possibly add more context to the error that wasmtime::component::Linker generated

This "add context" method would look something along the lines of:

Enable all -S... options and attempt to create an InstancePre. If that fails then don't add context and just return an error.

If that succeeds then for every -S option turn it back off and see if creation of InstancePre still fails. If creation succeeds, leave it off, otherwise leave it on.

At the end diff -S options with what the user provided, adding context to the error saying "did you mean -Scli,http" or similar

That's a little involved but in theory should be pretty robust in the face adding/removing methods over time and such. It'd also handle the case of something like -Sexit-with-code which is pretty different from cases of "the entire interface is missing"

Wasmtime GitHub notifications bot (Feb 26 2025 at 09:54):

vados-cosmonic commented on PR #10259:

Thanks for the basic layout of the plan! That sounds good -- a bit surprised with the creating of the InstancePre being the best way to test -- I was thinking that we could look up based on the type information coming back from the error, but I guess the idea is that we can do this approach without trying to pass along which import was broken?

Wasmtime GitHub notifications bot (Feb 26 2025 at 16:23):

alexcrichton commented on PR #10259:

Yeah that's the theory, and also relying on all the same machinery in wasmtime for type-checking and stuff without replicating it in the CLI

Last updated: Feb 28 2025 at 02:27 UTC