This is a tracking issue for adding support for the console API to the web-sys crate.
General info on the console API: https://developer.mozilla.org/en-US/docs/Web/API/Console
How to add support for new Web APIs to web-sys: https://rustwasm.github.io/wasm-bindgen/web-sys/supporting-more-web-apis.html
Here is a list of interfaces we need to support:
Consoleexamples/ to use web-sysBuilding web-sys after moving the Console webidl file to enabled results in the following console output. I wasn't able to figure out if its an error in the file or the parser or the web-sys crate.
--- stdout
cargo:rerun-if-changed=build.rs
cargo:rerun-if-changed=webidls/enabled
cargo:rerun-if-changed=webidls/enabled/StorageType.webidl
cargo:rerun-if-changed=webidls/enabled/DOMHighResTimeStamp.webidl
cargo:rerun-if-changed=webidls/enabled/Console.webidl
cargo:rerun-if-changed=webidls/enabled/Response.webidl
cargo:rerun-if-changed=webidls/enabled/Event.webidl
--- stderr
Error: compiling WebIDL into wasm-bindgen bindings
caused by parsing WebIDL source text
caused by Unrecognized token `Const` found at 2861:2866
Expected one of "(", "ArrayBuffer", "ByteString", "DOMString", "DataView", "Error", "Float32Array", "Float64Array", "FrozenArray", "Identifier", "Int16Array", "Int32Array", "Int8Array", "Promise", "USVString", "Uint16Array", "Uint32Array", "Uint8Array", "Uint8ClampedArray", "any", "boolean", "byte", "double", "float", "long", "object", "octet", "readonly", "record", "sequence", "short", "symbol", "unrestricted", "unsigned" or "void"
@jannikkeye, can you minimize the test case and file a bug upstream?
I'm not entirely sure since I'm rather new to webidl but it seems that const can only appear in an interface: https://heycam.github.io/webidl/#idl-constants
But in console.webidl it appears inside the namespace console: https://github.com/rustwasm/wasm-bindgen/blob/3578a83fe2a4c2ad9be8bfaa26258a8a646e05ab/crates/web-sys/webidls/available/Console.webidl#L14-L76
In case I'm wrong, here's a minimal example to reproduce the issue with webidl-rs:
[Exposed=(Window)]
namespace console {
const boolean IS_NATIVE_CONSOLE = true;
};
Two thoughts:
This particular constant is ChromeOnly, so I think we can safely comment it out and get on with our lives.
Might be worth filing that issue upstream with both the webidl crate and the spec anyways.
If you comment out the incorrect const, then it builds, but you still don't have access to console functions because they are defined like this:
[Exposed=(Window,Worker,WorkerDebugger,Worklet,System),
ClassString="Console",
ProtoObjectHack]
namespace console {
// ...
which I'm guessing means "these are exposed on the (window/worker/...) prototype as console, which has class name Console.
So should web-sys be something like
#[wasm_bindgen]
extern "C" {
#[wasm_bindgen(js_namespace = console)]
fn log(s: &str); // not the correct type
}
and then, how do you stop name collisions from functions with the same name in different namespaces? Should web-sys generate modules to match namespaces?
@derekdreery That's basically what is suggested in #253. I think getting webidl namespace support first would be very helpful to get the Console.webidl up and running properly.
Thanks for linking the issue :)
Brain dump:
Rather than being like arbitrarily nested rust modules, a WebIDL namespace is like a global singleton object with methods. So console is like someone has done var console = new Console() at the beginning of each page. So we can still use modules from rust, but we should note the semantic differences.
Now that #678 has landed, what's left to do for this issue?
@eminence If I'm not completely mistaken, generating variadic functions like log and warn are not yet supported. See also #503.
@migerh @eminence I'm work towards adding variadic support in #726. After that lands, I'll modify the webidl frontend to emit variadic functions (where the last arg is a slice/vec). There's also variadic the other way, as in passing a rust callback that is called variadically by javascript. I think we need this to support some callbacks, e.g. for events.
Most helpful comment
Two thoughts:
This particular constant is
ChromeOnly, so I think we can safely comment it out and get on with our lives.Might be worth filing that issue upstream with both the webidl crate and the spec anyways.