winch: Gracefully handle compilation errors #9851
Conversation
Closes: bytecodealliance#8096 This commit threads `anyhow::Result` through most of Winch's compilation process in order to gracefully handle compilation errors gracefully instead of panicking. The error classification is intentionally very granular, to avoid string allocation which could impact compilation performance. The errors are largely fit in two categories: * Unimplemented/Unsupported * Internal The firs category signals partial or no support for Wasmtime features and or Wasm proposals. These errors are meant to be temporary while such features or proposals are in development. The second category signals that a compilation invariant was not met. These errors are considered internal and their presence usually means a bug in the compiler.
Subscribe to Label Action
This issue or pull request has been labeled: "winch"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
This category seems like it should probably result in panics? At least, in the outer winch compilation driver code? |
|
Ultimately it should I think: thinking through a bit more I don't think there's a case in which we want to bubble these errors up as recoverable. Given the classification done in this PR I think it'll be easy to check (at the top level) if the contained error is internal and panic at that point. I'll add that in. |
There was a problem hiding this comment.
LGTM.
Don't really need to address the comment about internal errors before landing this (or even at all, if there is good motivation I am missing).
FWIW, if you are only using custom errors, it may make sense to avoid using anyhow::Result and anyhow::Error all through winch and just define a custom type Result<T, E = WinchError> = core::result::Result<T, E>;.
Closes: #8096
This commit threads
anyhow::Resultthrough most of Winch's compilation process in order to gracefully handle compilation errors instead of panicking.The error classification is intentionally very granular, to avoid string allocation which could impact compilation performance.
The errors largely fit in two categories:
The firs category signals partial or no support for Wasmtime features and or Wasm proposals. These errors are meant to be temporary while such features or proposals are in development.
The second category signals that a compilation invariant was not met. These errors are considered internal and their presence usually means a bug in the compiler.