-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing String Enums #3057
Comments
String enums are already supported; see https://rustwasm.github.io/wasm-bindgen/reference/types/imported-js-types.html. (I'm not sure why they're in that section; surely they should be under 'Exported Rust Types'?) |
They are in the docs, but if I try to use them they don't output any typescript types. If you have a mixed enum, e.g.
You get the error 'enums with #[wasm_bindgen] may only have number literal values' - which is from here. https://github.com/rustwasm/wasm-bindgen/blob/main/crates/macro-support/src/parser.rs#L1288 I was assuming the docs were wrong - but if there is a way to make this work that would be great. |
I've put a minimal reproducible example at https://github.com/JohnGinger/string-enum-example. The exported types are only
|
That's a bug, the types should be emitted.
That's a bad error message - it should be saying something like 'enums must have either all string or all int payloads'. In fact, it does give a better error message is you swap the order of the variants around - this: #[wasm_bindgen]
#[derive(Copy, Clone, Debug)]
pub enum StringEnum {
Bar = "bar",
Qux = "qux",
Foo = 1,
} gives this error message:
So, it should be fixed to always give that message. |
Okay, it's slightly more complicated than I first thought - unlike regular enums, string enums are allowed to be private, and string enums defined deep in the dependency tree shouldn't be getting top-level type declarations. So, some logic will be needed to only add the type declarations if they're exported from the crate root. |
Thanks for being so responsive. I'm happy to help fix this, any pointers as to where I should start? |
String enums are parsed here: wasm-bindgen/crates/macro-support/src/parser.rs Lines 1168 to 1212 in f75a3f8
Their AST is converted to the type passed from the macro to the CLI here: wasm-bindgen/crates/backend/src/encode.rs Lines 315 to 317 in f75a3f8
That type is defined here (currently empty): wasm-bindgen/crates/shared/src/lib.rs Line 91 in f75a3f8
I think that's most of the places you'd have to change, so hopefully that's helpful! Also, I already wrote a fix for the bad error message in 6ed8f5b, if you want to start from there. |
Oh, and you'll want to put the list of string enums somewhere in this struct to pass to the JS generation stage: wasm-bindgen/crates/cli-support/src/wit/nonstandard.rs Lines 8 to 62 in f75a3f8
And then actually generate the JS in here: wasm-bindgen/crates/cli-support/src/js/mod.rs Lines 2384 to 2415 in f75a3f8
|
I would like to work on this bug ~ thanks ~ |
Go for it, sorry I haven't got round to it |
I tried to at least improve the situation by changing the type from |
The type is wasm-bindgen/crates/backend/src/codegen.rs Lines 1084 to 1088 in def9147
It's possible to keep them as wasm-bindgen/src/convert/slices.rs Lines 227 to 240 in def9147
It's a bit weird that they're passed as |
Motivation
At the moment number enums are supported. e.g.
I would like to support string enums as well e.g.
Proposed Solution
I would be happy to implement this, is it something that a PR would be accepted for?
The text was updated successfully, but these errors were encountered: