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
Missing WebIDL processing features overview #3921
Comments
Just a quick comment on this one: allowing to unset values would effectively void the conditions that should hold for reading the properties. Meaning that all getters would need to be wrapped in an I guess you could implement the |
Not all of them - the UPD: oh, yeah, dictionaries, right. They don't have definitions like that, and thus must absolutely always do the explicit |
They actually do, so I think your suggestion of allowing to unset optional values only would work great. E.g. the first dictionary declaration I could find going alphabetically in the enabled WebIDLs: wasm-bindgen/crates/web-sys/webidls/enabled/AnalyserNode.webidl Lines 13 to 18 in e78db23
It just looks like the code generation for dictionary constructors produces undefined behavior by not setting default values in wasm-bindgen/crates/web-sys/src/features/gen_AnalyserOptions.rs Lines 30 to 38 in e78db23
I'll open a separate issue for that. |
I was doing a manual implementation for the WebTransport types, and here's case-study-based a list of missing features that makes WebIDL codegen really unusable:
ReadableStream
, pretty much everywhere in thegetStats
for WebTransport, etc.Option<T>
instead ofT
, or generate an additional accessor to allowunset_...
.js_sys::Promise
it returned instead. We should consider adding types support to thejs_sys::Promise
, and also generating the calls that return promises as realasync fn
s. This is, however, blocked by Add.into()
to the generated code for async fns #3919, asasync
fn generation is broken..into()
to the generated code for async fns #3919. Theasync
fn generation is broken.catch
is not generated correctly. This is an issue with WebIDL definitions, as they lack the machine-readable data on whether a call can throw or not - but nonetheless I count this towards the list of issues of the WebIDL-generated rust code.ReadableStream
/WriteableStream
should have a generic indicating what type they produce - they are capable of streaming not just the bytes (i.e. binary data, where they act like Read/Write), but objects too (acting more like a stream / async iterator in rust sense).final
at the codegen level.wasm_bindgen_webidl
as a dependency and use it in my crate - as the latest version is not published, and the last published is very old and conflicts with the rest of the crates. This is by far the easiest issue to solve.Also, some nits I encountered while implementing things manually.
missing_docs
lint is triggered forwasm_bindgen
macro enums.wasm_bindgen
macro, as in syntax sugar for generating both getter and setter from the same attribute.Not sure this is the right place for this, and those issue are most definitely reported before - but this is a case study organized in one place, and will hopefully act like a concise roadmap towards a better support for WebIDL. Hopefully if all those are solved somehow we'd get a way nicer codegen.
For now, using WebIDL is much more painful than using custom type declarations.
The text was updated successfully, but these errors were encountered: