WebIDL: Handle Invalid Enum Returns

[Slowki]

As discussed in #260 and #433 there are two main ways to handle invalid enum returns from JS in the WebIDL codegen:

Method 1

Convert enum returns in WebIDL to Result<ENUM, String>s

Advantages

• Fairly ergonomic and idiomatic
• You can add special handling logic for browser specific returns by examining the String in Err

Disadvantages

• Additive changes will break any matchs that don't have a wildcard arm(unlike in Method 2, which forces a wildcard match), so the user might have to change their code when they update their web-sys version

Method 2

Non-exhaustive enums.

Advantages

• Any additive changes to the WebIDL enums(and as such the web-sys crate's Rust enum variants) don't break code because non-exhaustive enums force wildcard matches

Disadvantages

• Not very ergonomic on the end user since their code could end up with a lot of wildcard matches even in cases where the enum is coming from their own Rust code
• Wildcard matches wouldn't give you specific information on the value returned(unless we want to make the enums un-copyable), just that it wasn't one of the known variants, so you couldn't add special handling for browser specific return values

I opted for Method 1 because it seems like it gives the cleanest code when using enums, and I like the idea of being able to handle browser specific returns that aren't document in WebIDL. Do you folks agree, or should we go with Method 2/something else?

Closes #260

[alexcrichton]

Since this doesn't actually need ownership, should this take &JsValue?

[alexcrichton]

I've just realized (after the fact, sorry!) that in other places in wasm-bindgen we don't explicitly list derive modes but rather pass through the original annotations. Here there's no #[wasm_bindgen] equivalent for generating an imported enum so it doesn't matter too too much, but long-term we may want this line to be #(#rust_attrs)* and store attributes in the ImportEnum

[Slowki]

👍

[alexcrichton]

I'm a little wary of adding a trait like this, I'm afraid it'll be difficult to work with in general. The conversion traits are used in various locations throughout imports/exports/closures/etc. This also necessitates FromWasmAbi for Result which seems unfortunate in the sense that you can't do:

#[wasm_bindgen]
pub fn foo(a: CustomEnumType) {
    // ...
}

but are instead forced to do:

#[wasm_bindgen]
pub fn foo(a: Result<CustomEnumType, String>) {
    // ...
}

I might be leaning a bit towards dealing with nonexhaustive enums due to this interaction of how to add implicit conversions? I would also be ok, though, having a fallible constructor in Rust but panicking in the conversions at the boundary (as it seems like that's what may happen most of the time anyway?)

[Slowki]

Non-exhaustive enums are fine by me, the only awkward thing with them is the potential panic if the Rust code gets an invalid enum then tries to return it back to JS, which I can't think of a decent way around.

[alexcrichton]

Awesome, thanks!