Implement getters for WebIDL dictionaries

[pablosichert]

Heyo,

this PR implements getters for WebIDL dictionaries. The diff is bit noisy due to the autogenerated files; you can look at the actual changes to the code generation in the last two files crates/webidl/src/generator.rs and crates/webidl/src/lib.rs and corresponding tests in crates/webidl-tests/dictionary.rs.

Currently, setters are implemented as my_property(&mut self, val: ...). To avoid breaking backwards compatibility, I have generated a new trait MyDictionaryTypeGetters for every MyDictionaryType. It contains definitions in the form of my_property(&self) -> ....

Personally, I would suggest to rename all setters to set_my_property and place the my_property getters back in the impl MyDictionaryType as conventionally used in Rust. Preferably in another PR since as already mentioned would break backwards compatibility.

For the dictionary getter return types I have applied the same logic that is currently used for Interface getters:

wasm-bindgen/crates/webidl/src/lib.rs

Lines 688 to 692 in e78db23

	let ty = type_
	.type_
	.to_idl_type(self)
	.to_syn_type(TypePosition::Return)
	.unwrap_or(None);

wasm-bindgen/crates/webidl/src/generator.rs

Lines 298 to 300 in e78db23

	"Getter",
	quote!(getter,),
	quote!( pub fn #name(#this) -> #ty; ),

This should close #1793 and #2921, and address point 1 of #3921.

[pablosichert]

That's the main addition of this PR...

[pablosichert]

...with getter signatures that are defined here...

[pablosichert]

...and implemented here

[MOZGIII]

Personally, I would suggest to rename all setters to set_my_property and place the my_property getters back in the impl MyDictionaryType as conventionally used in Rust. Preferably in another PR since as already mentioned would break backwards compatibility.

I agree. We should bite the bullet, break the compatibility and do it (in another PR ofc).

[MOZGIII]

I like the idea of having traits here. We could probably go even further - have a trait with a WebIDL-generated declaration of the whole interface of a given type - not just for getters. That way we can include getters, setters and methods (both static and not).
The possible benefit from this would be nicer composability of wasm types.

I think we could create an issue to discuss this further, if this sounds like a viable direction to explore.

[pablosichert]

The possible benefit from this would be nicer composability of wasm types.

I think you are referring to what I have an mind, but just to elaborate the thought: I'm not fully sure yet how hard it would be to make it possible, but if that would allow e.g. implementing FooGetters for Bar where Bar: Foo, that would be great. Currently you need to explicitly downcast the type.

[pablosichert]

Unfortunately, due to the signature name clash this is a bit awkward to use right now.

If you move the use crate::generated::ManyTypesGetters; to the parent block, this test breaks.

[MOZGIII]

See #3934

---

Let's take a WritableStream for example.

If it was a trait, could just implement it for a JsValue, like so: impl WritableStream for JsValue { ... } (with some codegen of course).

Then, if needed, we could very elegantly extend WritableStream with WebTransportSendStream with an explicit trait WebTransportSendStream: WritableStream { ... } - and also implement the WebTransportSendStream for JsValue.

---

With the given WebIDL:

WebIDL

[Exposed=*, Transferable]
interface WritableStream {
  constructor(optional object underlyingSink, optional QueuingStrategy strategy = {});

  readonly attribute boolean locked;

  Promise<undefined> abort(optional any reason);
  Promise<undefined> close();
  WritableStreamDefaultWriter getWriter();
};

[Exposed=(Window,Worker), SecureContext, Transferable]
interface WebTransportSendStream : WritableStream {
  attribute WebTransportSendGroup? sendGroup;
  attribute long long sendOrder;
  Promise<WebTransportSendStreamStats> getStats();
  WebTransportWriter getWriter();
};

The traits would look somewhat like this:

Traits

trait WritableStream: Sized + JsAny {
    fn new() -> Self;
    fn new_with_underlying_sink(underlying_sink: &impl JsObject) -> Self;
    // ...

    fn locked(&self) -> bool;

    fn abort(&self) -> Promise<()>;
    fn abort_with_reason(&self, reason: &impl JsAny) -> Promise<()>;

    fn close(&self) -> Promise<()>;

    fn get_writer(&self) -> Result<impl WritableStreamDefaultWriter>;
}

trait WebTransportSendStream: WritableStream + JsAny {
    fn send_group(&self) -> Option<impl WebTransportSendGroup>;
    fn set_send_group(&self, value: &impl WebTransportSendGroup) -> Option<impl WebTransportSendGroup>;
    fn unset_send_group(&self);

    fn send_order(&self) -> i64;
    fn set_send_order(&self, value: i64);
    fn unset_send_order(&self);
    
    fn get_stats(&self) -> Promise<impl WebTransportSendStreamStats>;

    fn get_writer(&self) -> Result<impl WebTransportWriter>;
}

and impls like this:

Impls

impl WritableStream for JsValue {
    fn new() -> Self {
        __shim_WritableStream_new()
    }

    fn new_with_underlying_sink(underlying_sink: &impl JsObject) -> Self {
        __shim_WritableStream_new_with_underlying_sink(underlying_sink)
    }

    // ... and so on.
}

impl WebTransportSendStream for JsValue {
    fn send_group(&self) -> Option<impl WebTransportSendGroup> {
        __shim_WebTransportSendStream_send_group()
    }

    // ... and so on.
}

---

A couple things to note:

• the idea of having a JsAny type, that would work somewhat like a dyn std::any::Any and enable typechecking of the underlying type of any JsValue:

  let random_value: JsValue = ...;
  let stream: impl WebTransportSendStream = JsAny::as_unchecked<dyn WebTransportSendStream>(random_value); // might also have an `instanceof` and/or custom guard variants.

  UPD: no! actually, what we just need is this: trait JsAny { fn as_js_value(self: Self) -> JsValue }; JsValue already has all the impls, so this effectively allows us to cast impl WebTransportSendStream to JsValue and from there to anything:

  let random_value: JsValue = ...;
  // Works cause of impl WebTransportSendStream for JsValue.
  let stream: impl WebTransportSendStream = random_value;
  // Works cause WebTransportSendStream: WritableStream.
  let stream: impl WritableStream = stream;
  //  Doesn't work, as this type of generalization is not necessarily ture: not every `impl WritableStream` is a `impl WebTransportSendStream`
  let stream: impl WebTransportSendStream = stream;
  //  This works though.
  let stream: impl WebTransportSendStream = JsAny::as_js_value(stream);

  This might look scary - but you would just always use generics or trait object if an issue is encountered here.

  Also, we should consider having something like this: JsValue<dyn WebTransportSendStream> - the JsValue is already effectively a pointer to a value, but this way it can also carry on the information about the associated API.

  Then we'd implement the traits for impl WebTransportSendStream for JsValue<dyn WebTransportSendStream> { ... } to provide the type restrictions...

• the shims being standalone functions instead of being implementation details of a given type.

[pablosichert]

Cool, tests pass now.

Just a note that this will break for people that use web_sys::* in their code, but I guess they should be aware that they are opening up to that danger by using a wildcard.