WebAssembly

[NeverGivinUp]

Are you planning to support or already supporting compiling to WASM? Where would I find instructional documentation? I think there already is some support for compiling Kotlin to WASM, so that could be an starting point for the WASM side. WASM requires Javascript support, to really do stuff in the browser. So this might be a compile target suited specifically for WebStorm-integration. Also: support for Yew would be great.

---

META TODO

Feature support list:

• WebAssembly projects creation in New project dialog
  • cargo-generate templates
  • Native Cargo templates RFC - cargo templates rust-lang/rfcs#2922
• wasm-pack run configurations
  • Commands completion
  • Build tool window for build and test commands
• wasm-pack commands in Run Anything
• wasm-bindgen tests Custom test runner run context configuration #3007
• Rust <-> JS interop
  • Rust->JS navigation
  • JS->Rust navigation
  • Cross-language refactorings support
• npm integration
  • Set up a web page using npm init wasm-app and npm install
  • Provide run configuration npm run start
• Debugging of WebAssembly projects
  • Plain Rust+Wasm web projects
  • Rust+Wasm web projects with wasm-bindgen (blocked by Support DWARF in wasm-bindgen rustwasm/wasm-bindgen#2389)
  • Debugging when running in standalone runtime (e.g. wasmtime)
• Auto refresh/rebuild on changes (watch and serve subcommands) Add watch and serve subcommands to wasm-pack rustwasm/rfcs#10
• Documentation
  • cargo-generate
  • wasm-pack

[vlad20012]

Hmm, what kind of support do you expect from IDE? "Compiling" is a responsibility of, well, the compiler =) You can find an appropriate instruction about compiling Rust to wasm in wasm-pack or stdweb projects. If you know some specific wasm-related features you expect from our plugin, feel free to list them =)

Btw IntelliJ-Rust works in WebStorm, and IntelliJ IDEA Ultimate also supports JavaScript.

[NeverGivinUp]

"Compiling" is a responsibility of, well, the compiler =)

That is certainly true! But there is also project structure, dependency management to and from Javascript libraries, packaging, deployment, debugging an app running in the browser and interacting with the DOM. You might consider separate sub project types for WASM projects, Web Components written in WASM, single page apps written in Yew.

[vlad20012]

It's interesting. Ok, for now we made literally nothing about WASM support. And to be honest, I know too little about it. If you can describe what exactly we can do to help wasm developers, feel free to open specific issues about it. For example, there is an issue about wasm test runners #3007. It could be a good issue "Support run Yew apps", for example.

[ponchofiesta]

To run wasm-pack from run configuration like Cargo would be a start.

[SnowyCoder]

The current intellij-rust does not recognize any object provided by web_sys, and that is quite annoying as that means that there is no auto-completition support.

[vlad20012]

@SnowyCoder
There are 2 problems with web-sys:

1. It requires include macro support. We currently actively working on it, see Handle include!(concat!(env!("OUT_DIR"), "/bindings.rs")); #1908 (MACRO&RES: initial version of include macro support #3935)
2. wasm-bindgen generate too large source file for web-sys. IntelliJ source file size limit is about 2.5 Mb, when web-sys's bindings.rs can be of 10 Mb in size (depending on active features). Looks like we can't solve it on our side and it's really needed to split web-sys's bindings.rs into multiple files on web-sys side. I think we'll start to discuss this possibility with web-sys developers when we'll finish work on include.

UPD: IntelliJ platform has 2 file size limits. The first one can be adjusted with system property -Didea.max.intellisense.filesize=3500 (number in kilobytes, 2500 by default, can't be greater than 20 MB). This check can also be disabled for specific VirtualFile by calling doNotCheckFileSizeLimit() method (but looks like it's designed for LightVirtualFiles). The second limit is 20 MB. It is unadjustable and it isn't possible to disable it.

[tiberiusferreira]

Hello, thanks for the great work on it so far.

Just to clarify, since the plugin supports 2 out of the 3 major include scenarios, it is already possible to get completions for websys by setting Didea.max.intellisense.filesize=20000 and not having too many web sys features activated?

I tried it, but it doesn't work on my setup. Just wondering if it is not supported yet or if I'm missing some config.

UPDATE:
Nevermind, just checked the source and web sys uses the only unsupported include case: include!(env!("BINDINGS"));

[edvorg]

On a side note. I used intellij idea to develop a web project that is made 100% in rust (native + wasm). I used a multiproject setup, with common parts of the logic written in a shared project that is used as dependency on backend and frontend.

Surprisingly, EVERYTHING worked really well. Code completion, code navigation, refactoring in both frontend and backend. I did not expect it. Big thanks to developer of rust plugin!

If you're interested to checkout how the project is setup you may take a look here https://github.com/edvorg/rustmith, but there is nothing idea-specific there really. Just a standard cargo project.

[HughPH]

Thank you @edvorg , as a C# developer coming from Rider and previously VS, I'm 'spoilt' - I just want to write code, add some breakpoints and hit the 'debug' button, it's tiring having to learn so many new tools so often and I'm trying to distance myself from the ever-twisting clusterfunk that seems to be what's become of the modern JavaScript landscape.

Regarding @NeverGivinUp 's original question, my interpretation of "Integrated" Development Environment is that it "Integrates" all the tools - including whatever compilers are required. Again, back to my C# point, if I add a file type that's supported, I would expect the IDE to compile it without me having to do anything (except perhaps download the compiler of my choice and perhaps make a selection in the IDE.) Now, the Rust Plugin does do this very well for what it supports, and I'm largely delighted with how easy it is to create a command-line app in Rust and be able to debug it. But one of the main points of Rust is that you can create WASM Libraries with it (it's on the rust-lang.org front page FFS) so simply not doing anything for WASM seems to me like the ball has been dropped.

[tiberiusferreira]

Is there a workaround for web sys? I use it regularly and it is really annoying. :(

[panstromek]

With the latest release (116), web_sys intellisense works if you:

1. Enable org.rust.cargo.evaluate.build.scripts in experimental features
   (double shift -> experimental features)

2. Increase the filelimit (as pointed out above)
   (help -> Custom VM options)
   Put this line into the file: -Didea.max.intellisense.filesize=20000

3. Maybe restart the IDE? I think I needed to do it...

[EDIT]

4. Set web_sys version to =0.3.35 until Auto complete not working on wildcard re-exports of another crate #4830 (and therefore Code completion regression in web-sys? #5104) gets resolved.
   As mentioned in later comments and other issues, since version 0.3.36 , web_sys` doesn't use build script to generate bindings anymore, so the support is blocked on different intellij-rust bug (Auto complete not working on wildcard re-exports of another crate #4830)

[tiberiusferreira]

It works! Absolutely fantastic! Thank you very much to everyone involved, this made my day!

[thecodewarrior]

This still isn't working for me, even with the changes @panstromek mentioned. It's not even a simple "it doesn't work" either since in some cases it is kind of working, but it's working incorrectly.

I have this in my Cargo.toml:

[dependencies.web-sys]
version = "0.3.36"
features = [
  'CanvasRenderingContext2d',
  'Document',
  'Element',
  'HtmlCanvasElement',
  'Window',
]

and here's some code that exhibits the issue:

fn foo() {
    let document: web_sys::Document = web_sys::window().unwrap().document().unwrap();
    let document: web_sys::Document = web_sys::document(web_sys::window().unwrap()).unwrap();
}

That code has three different parts:

• The part that does work is that it can see web_sys::window(), presumably since it's defined in the root lib.rs file.
• The simple "it doesn't work" issue is that it can't seem to see (i.e. I can't "go to definition") any of the types, in this case, web_sys::Document.
• The part that kind of works, albeit incorrectly, is that on the first line, IntelliJ-Rust can't find the document function, but on the second line it can. The strange part is that the first line compiles but the second one doesn't, so IntelliJ-Rust is failing on the correct code and succeeding on the incorrect code. The function it jumps to is this one, in gen_Window.rs:

#[wasm_bindgen]
extern "C" {
    // ...
    #[cfg(feature = "Document")]
    # [ wasm_bindgen ( structural , method , getter , js_class = "Window" , js_name = document ) ]
    #[doc = "Getter for the `document` field of this object."]
    #[doc = ""]
    #[doc = "[MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/document)"]
    #[doc = ""]
    #[doc = "*This API requires the following crate features to be activated: `Document`, `Window`*"]
    pub fn document(this: &Window) -> Option<Document>;
    // ...
}

My current build versions are:

• Rust nightly (rustc 1.43.0-nightly (158127853 2020-03-10))
• The latest build of the IntelliJ-Rust (117)
• The latest EAP build of IntelliJ IDEA (IntelliJ IDEA 2020.1 EAP (Ultimate Edition), Build #IU-201.6073.9)

I set the two options mentioned by @panstromek, I've tried this with both the default and experimental macro engines, and tried restarting IntelliJ all along the way. Note that when I look at the features/mod.rs file it does correctly highlight the enabled/disabled features (it makes the disabled features a faded "inactive" color).

The relevant web_sys code

web_sys's lib.rs file contains these:

mod features;
pub use features::*;

// ...

#[cfg(feature = "Window")]
pub fn window() -> Option<Window> {

The features module's mod.rs file contains a bunch of these:

// ...
#[cfg(feature = "Window")]
#[allow(non_snake_case)]
mod gen_Window;
#[cfg(feature = "Window")]
pub use gen_Window::*;
// ...

The gen_Window module contains a bunch of these:

#[wasm_bindgen]
extern "C" {
    // ...
    #[cfg(feature = "Document")]
    # [ wasm_bindgen ( structural , method , getter , js_class = "Window" , js_name = document ) ]
    #[doc = "Getter for the `document` field of this object."]
    #[doc = ""]
    #[doc = "[MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/document)"]
    #[doc = ""]
    #[doc = "*This API requires the following crate features to be activated: `Document`, `Window`*"]
    pub fn document(this: &Window) -> Option<Document>;
    // ...
}

[thecodewarrior]

I've managed to track down the root issue, and it seems to be caused by wasm_bindgen and #1786. Here's a minimal test case for the behavior:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen]
    fn global() -> Foo;

    type Foo;

    /// https://rustwasm.github.io/docs/wasm-bindgen/reference/attributes/on-js-imports/constructor.html
    #[wasm_bindgen(constructor)]
    fn new() -> Foo;

    /// https://rustwasm.github.io/docs/wasm-bindgen/reference/attributes/on-js-imports/method.html
    #[wasm_bindgen(method)]
    fn method(this: &Foo);

    /// https://rustwasm.github.io/docs/wasm-bindgen/reference/attributes/on-js-imports/static_method_of.html
    #[wasm_bindgen(static_method_of = Foo)]
    fn static_foo() -> Foo;
}

/// This compiles, but go to definition on `Foo`, `new`, `method`, and `static_foo` doesn't work.
/// The `global` function resolves fine though.
fn correct() {
    global();
    let new_foo: Foo = Foo::new();
    new_foo.method();
    let static_result = Foo::static_foo();
}

/// This does not compile, but go to definition on `new`, `method`, and `static_foo` work.
/// The `Foo` type is still broken and the `global` function resolves fine.
fn incorrect() {
    global();
    let new_foo: Foo = new();
    method(new_foo);
    let static_result = static_foo();
}

[ta32]

please support rust wasam in the rust plugin. I dont want to keep invoking things from the command line. There should be a build and run tests command template just like there is for cargo.

[gilescope]

Would be nice to be able to debug into tests run as wasm32-unknown-unknown.