Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasi-sockets: Add network-error-code #9276

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

badeend
Copy link
Contributor

@badeend badeend commented Sep 18, 2024

Implements WebAssembly/wasi-sockets#105

This function downcasts a stream error to a network-related error.
Similar to the existing filesystem-error-code and http-error-code functions.

Unit test is missing because I couldn't figure out a reliable way to fail a TCP stream mid-connection. Suggestions are welcome.

@badeend badeend requested a review from a team as a code owner September 18, 2024 09:32
@badeend badeend requested review from elliottt and removed request for a team September 18, 2024 09:32
@github-actions github-actions bot added the wasi Issues pertaining to WASI label Sep 18, 2024
…imilar to the existing `filesystem-error-code` and `http-error-code` functions.
@alexcrichton
Copy link
Member

Thanks for this! Before I think too hard about a unit test though this PR is the unfortunate victim of "first proposal to add WITs with @unstable". As implemented this provides unrestricted access to the @unstable version of the API which is not the intention of the annotation. The theory is that @unstable would translate to some sort of -S flag such as -Snetwork-error-code or something like that. That would be there during development and then when @unstable is turned to stable then -Snetwork-error-code becomes a noop effectively.

I say that this is an "unfortunate victim" because this infrastructure hasn't been built yet. Ideally what needs to happen I think is that the calls to add_to_linker all need to be parameterized by feature flags where the default is the empty set. So in a sense we need a set of flags for all WASI proposals which are passed during the original call to add_to_linker and then that set is built up on the CLI.

From a technical perspective though this PR otherwise looks good to me. Would you be up for helping out with the infrastructure for plumbing flags through?

@badeend
Copy link
Contributor Author

badeend commented Sep 18, 2024

I'll give it a try

@badeend
Copy link
Contributor Author

badeend commented Sep 18, 2024

Do you have any preference on how to thread through the feature names down into the generated code? I have three suggestions so far:

  • Add component_model_unstable_features setting to wasmtime::Config
  • Add unstable_features setting to wasmtime::component::Linker
  • Add features parameter to generated add_to_linker_* methods and all layers below and above it.

@alexcrichton
Copy link
Member

I'd recommend the add_to_linker_* route and it would automatically be used when features is specified in the bindgen! macro (it's a WASI-specific or bindings-specific thing, less about engine state)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasi Issues pertaining to WASI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants