kubkon opened PR #1253 from error-cleanup to master:
This PR builds on #1243.
WasiCtxBuilderErroris thewasi-commonclient-facing error type which is exclusively thrown when building a newWasiCtxinstance. As such, building such an instance should not require the client to understand different WASI errno values as was assumed until now.This commit is a first step at streamlining error handling in
wasi-commonand makes way for thewigglecrate.When adding the
WasiCtxBuilderError, I've had to do two things of notable importance:
- I've removed a couple of
ok_orcalls inWasiCtxBuilder::buildand replaced them withunwraps, following the same pattern in different builder methods above. This is fine since we _always_ operate on non-emptyOptions inWasiCtxBuilderthusunwraping will never fail. On the other hand, this might be a good opportunity to rethink the structure of our builder, and how we good remove the saidOptions especially since we always populate them with empty containers to begin with. I understand this is to make chaining of builder methods easier which take and return&mut selfand the same applies toWasiCtxBuilder::build(&mut self)method, but perhaps it would more cleanly signal the intentions if we simply movedWasiCtxBuilderinstance around. Food for thought!- Methods specific to determining rights of passed around
std::fs::Fileobjects when populatingWasiCtxFdEntryentities now returnio::Errordirectly so that we can reuse them inWasiCtxBuildermethods (returningWasiCtxBuilderErrorerror type), and in syscalls (returning WASI errno).ToDo:
- [x] introduce
WasiCtxBuilderError- [ ] return
WasiErrordirectly in syscalls- [ ] hence remove
error::Errortype- [ ] fix
wig
kubkon requested alexcrichton, pchickey, and sunfishcode for a review on PR #1253.
kubkon requested alexcrichton, pchickey, and sunfishcode for a review on PR #1253.
kubkon requested alexcrichton, pchickey, and sunfishcode for a review on PR #1253.
kubkon updated PR #1253 from error-cleanup to master:
This PR builds on #1243.
WasiCtxBuilderErroris thewasi-commonclient-facing error type which is exclusively thrown when building a newWasiCtxinstance. As such, building such an instance should not require the client to understand different WASI errno values as was assumed until now.This commit is a first step at streamlining error handling in
wasi-commonand makes way for thewigglecrate.When adding the
WasiCtxBuilderError, I've had to do two things of notable importance:
- I've removed a couple of
ok_orcalls inWasiCtxBuilder::buildand replaced them withunwraps, following the same pattern in different builder methods above. This is fine since we _always_ operate on non-emptyOptions inWasiCtxBuilderthusunwraping will never fail. On the other hand, this might be a good opportunity to rethink the structure of our builder, and how we good remove the saidOptions especially since we always populate them with empty containers to begin with. I understand this is to make chaining of builder methods easier which take and return&mut selfand the same applies toWasiCtxBuilder::build(&mut self)method, but perhaps it would more cleanly signal the intentions if we simply movedWasiCtxBuilderinstance around. Food for thought!- Methods specific to determining rights of passed around
std::fs::Fileobjects when populatingWasiCtxFdEntryentities now returnio::Errordirectly so that we can reuse them inWasiCtxBuildermethods (returningWasiCtxBuilderErrorerror type), and in syscalls (returning WASI errno).ToDo:
- [x] introduce
WasiCtxBuilderError- [ ] return
WasiErrordirectly in syscalls- [ ] hence remove
error::Errortype- [ ] fix
wig
kubkon edited PR #1253 from error-cleanup to master:
This PR builds on #1243.
WasiCtxBuilderErroris thewasi-commonclient-facing error type which is exclusively thrown when building a newWasiCtxinstance. As such, building such an instance should not require the client to understand different WASI errno values as was assumed until now.This commit is a first step at streamlining error handling in
wasi-commonand makes way for thewigglecrate.When adding the
WasiCtxBuilderError, I've had to do two things of notable importance:
- I've removed a couple of
ok_orcalls inWasiCtxBuilder::buildand replaced them withunwraps, following the same pattern in different builder methods above. This is fine since we _always_ operate on non-emptyOptions inWasiCtxBuilderthusunwraping will never fail. On the other hand, this might be a good opportunity to rethink the structure of our builder, and how we good remove the saidOptions especially since we always populate them with empty containers to begin with. I understand this is to make chaining of builder methods easier which take and return&mut selfand the same applies toWasiCtxBuilder::build(&mut self)method, but perhaps it would more cleanly signal the intentions if we simply movedWasiCtxBuilderinstance around. Food for thought!- Methods specific to determining rights of passed around
std::fs::Fileobjects when populatingWasiCtxFdEntryentities now returnio::Errordirectly so that we can reuse them inWasiCtxBuildermethods (returningWasiCtxBuilderErrorerror type), and in syscalls (returning WASI errno).ToDo:
- [x] introduce
WasiCtxBuilderError- [ ] return
WasiErrordirectly in syscalls- [x] hence remove
error::Errortype- [ ] fix
wig
kubkon edited PR #1253 from error-cleanup to master:
This PR builds on #1243.
WasiCtxBuilderErroris thewasi-commonclient-facing error type which is exclusively thrown when building a newWasiCtxinstance. As such, building such an instance should not require the client to understand different WASI errno values as was assumed until now.This commit is a first step at streamlining error handling in
wasi-commonand makes way for thewigglecrate.When adding the
WasiCtxBuilderError, I've had to do two things of notable importance:
- I've removed a couple of
ok_orcalls inWasiCtxBuilder::buildand replaced them withunwraps, following the same pattern in different builder methods above. This is fine since we _always_ operate on non-emptyOptions inWasiCtxBuilderthusunwraping will never fail. On the other hand, this might be a good opportunity to rethink the structure of our builder, and how we good remove the saidOptions especially since we always populate them with empty containers to begin with. I understand this is to make chaining of builder methods easier which take and return&mut selfand the same applies toWasiCtxBuilder::build(&mut self)method, but perhaps it would more cleanly signal the intentions if we simply movedWasiCtxBuilderinstance around. Food for thought!- Methods specific to determining rights of passed around
std::fs::Fileobjects when populatingWasiCtxFdEntryentities now returnio::Errordirectly so that we can reuse them inWasiCtxBuildermethods (returningWasiCtxBuilderErrorerror type), and in syscalls (returning WASI errno).ToDo:
- [x] introduce
WasiCtxBuilderError- [x] return
WasiErrordirectly in syscalls- [x] hence remove
error::Errortype- [ ] fix
wig
kubkon edited PR #1253 from error-cleanup to master:
This PR builds on #1243.
WasiCtxBuilderErroris thewasi-commonclient-facing error type which is exclusively thrown when building a newWasiCtxinstance. As such, building such an instance should not require the client to understand different WASI errno values as was assumed until now.This commit is a first step at streamlining error handling in
wasi-commonand makes way for thewigglecrate.When adding the
WasiCtxBuilderError, I've had to do two things of notable importance:
- I've removed a couple of
ok_orcalls inWasiCtxBuilder::buildand replaced them withunwraps, following the same pattern in different builder methods above. This is fine since we _always_ operate on non-emptyOptions inWasiCtxBuilderthusunwraping will never fail. On the other hand, this might be a good opportunity to rethink the structure of our builder, and how we good remove the saidOptions especially since we always populate them with empty containers to begin with. I understand this is to make chaining of builder methods easier which take and return&mut selfand the same applies toWasiCtxBuilder::build(&mut self)method, but perhaps it would more cleanly signal the intentions if we simply movedWasiCtxBuilderinstance around. Food for thought!- Methods specific to determining rights of passed around
std::fs::Fileobjects when populatingWasiCtxFdEntryentities now returnio::Errordirectly so that we can reuse them inWasiCtxBuildermethods (returningWasiCtxBuilderErrorerror type), and in syscalls (returning WASI errno).ToDo:
- [x] introduce
WasiCtxBuilderError- [x] return
WasiErrordirectly in syscalls- [x] hence remove
error::Errortype- [x] fix
wig
kubkon edited PR #1253 from error-cleanup to master:
WasiCtxBuilderErroris thewasi-commonclient-facing error type which is exclusively thrown when building a newWasiCtxinstance. As such, building such an instance should not require the client to understand different WASI errno values as was assumed until now.This commit is a first step at streamlining error handling in
wasi-commonand makes way for thewigglecrate.When adding the
WasiCtxBuilderError, I've had to do two things of notable importance:
- I've removed a couple of
ok_orcalls inWasiCtxBuilder::buildand replaced them withunwraps, following the same pattern in different builder methods above. This is fine since we _always_ operate on non-emptyOptions inWasiCtxBuilderthusunwraping will never fail. On the other hand, this might be a good opportunity to rethink the structure of our builder, and how we good remove the saidOptions especially since we always populate them with empty containers to begin with. I understand this is to make chaining of builder methods easier which take and return&mut selfand the same applies toWasiCtxBuilder::build(&mut self)method, but perhaps it would more cleanly signal the intentions if we simply movedWasiCtxBuilderinstance around. Food for thought!- Methods specific to determining rights of passed around
std::fs::Fileobjects when populatingWasiCtxFdEntryentities now returnio::Errordirectly so that we can reuse them inWasiCtxBuildermethods (returningWasiCtxBuilderErrorerror type), and in syscalls (returning WASI errno).With
WasiCtxBuilderErrorin place, we now can return a pureWasiErrorin all syscalls-related functions. This means we can completely removeerror::Errortype, and now,io::Errorand
related are automatically converted to their corresponding WASI errno value encapsulated asWasiError. IMHO this makes tracking errors in syscalls a lot cleaner and simpler.While here, it also made sense to me to move
WasiErrortowasimodule which will align itself well with the upcoming changes introduced bywiggle. To different standardResultfrom WASI specific, I've created a helper aliasWasiResultalso residing inwasimodule.Prereqs:
OK, while technically we only depend on #1243 since we're rebased on it, it'd be best if we landed #1255 before as well. So:
- [ ] #1243 landed
- [ ] #1255 landed
ToDo:
- [x] introduce
WasiCtxBuilderError- [x] return
WasiErrordirectly in syscalls- [x] hence remove
error::Errortype- [x] fix
wig
Last updated: Dec 13 2025 at 19:03 UTC