winch: Gracefully handle compilation errors

[saulecabrera]

Closes: #8096

This commit threads anyhow::Result through 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:

• 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.

[github-actions]

Subscribe to Label Action

cc @saulecabrera

This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

• saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[fitzgen]

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.

This category seems like it should probably result in panics? At least, in the outer winch compilation driver code?

[saulecabrera]

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.

[fitzgen]

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>;.

[saulecabrera]

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>;

Good point, I should've mentioned the rationale for going with anyhow rather than a custom Result<T, WinchError> in my commit message. That was my initial intention, however, since the code generation pass is intertwined with validation of other crates (e.g., wasmparser), I found it easier to handle cross-crate error definitions through anyhow, at the cost of a bit more verbosity in Winch's code base.