Error-context implementation slated for P3

[vados-cosmonic]

This issue is primarily to ensure we're at consensus regarding the current implementation for error-context happening in wasip3-prototyping and also being discussed here in other issues:

#474
#472
#469

After some discussion today the P3 path forward looks to be:

• Keep current error-context implementation
• Remove {stream,future}.close-{readable,writable}

The big question here/why this issue exists is to just make sure that there's appropriate agreement on the initial interface of error-contexts that's about to land, and the integration bits that are being held back.

There are many things that people want to see out of error-context as it evolves, but I agree with the initial assessment that the current implementation is a good first version of what will hopefully be a pervasive reusable error representation at the component model level.
(likely, many if not all of the above tickets can be closed if we are at consensus here)

cc @lukewagner @pchickey

[lukewagner]

I don't know if there's been more discussion elsewhere, but at the spec-level (not speaking to what's landed in the implementation) the point I thought we had reached is the two bullets at the top of the initial comment in #474, which are:

• Emoji-gate error-context in the explainer document (i.e., disable error-context entirely from 0.3.0)
• Remove error-context arguments/integration with futures/streams (i.e., remove the i32 error-context parameter from {stream,future}.close-{readable,writable}.

(With the intention to re-enable error-context in a subsequent 0.3.x release.)

[dicej]

• Emoji-gate error-context in the explainer document (i.e., disable error-context entirely from 0.3.0)

• Remove error-context arguments/integration with futures/streams (i.e., remove the i32 error-context parameter from {stream,future}.close-{readable,writable}.

In our meeting yesterday, we discussed doing the latter item but not the former in the wasip3-prototyping repo because we felt it would cause less churn overall. We can certainly do both in the spec, though. It's similar to how we punted on stackful (i.e. non-callback) async until post-0.3.0 but have left the implementation in place in wasip3-prototyping.

[alexcrichton]

To clarify, I think there are separate axes here and I think we're talking about subtly different things:

• Emoji gating - this'll be whether or not error-context is considered part of the 0.3.0 release from the point of view of the spec. This also affects the default validation features of wasmparser so, for example, if it remains emoji gated that means that wasm validation will reject such a component using error-context.
• Implementation - this is whether or not there's code in wasmtime/wit-bindgen/etc related to error-context. This is separable from emoji-gating because the "source of truth" is the validator and how it's configured.

In that sense @vados-cosmonic and @dicej are right in that we discussed we'll probably keep the error-context implementation in Wasmtime for now, but @lukewagner is also correct in that I think we'll want to, for now, emojit gate the validation and the spec.

I said this in the meeting as well but want to write it down here: I think it's fine to change this. If error-context becomes necessary for WASI then it is necessary and we should finish the design. If it's not necessary though (as I currently believe, but I have been wrong many times before) then this feels like the right balance of "gated but still implemented to play around with"

[vados-cosmonic]

Hey all I think we're aligned here, so in ~1 day I'm going to close this issue (and the other related issues about error-context) unless anyone has good reason to delay!