Ambiguous "unsafe" Error WASM JS alert

[dgb23]

I'm in the process of following the Game of Life Rust-WASM tutorial here:

https://rustwasm.github.io/docs/book/game-of-life/hello-world.html

My level of expertise in Rust: Beginner

OS: macOS Catalina 10.15.5
Editor: VSCode 1.47
rust-analyzer: v0.2.240

(rust-analyzer updated just a few minutes ago)

---

I'm getting this error message when looking at src/lib.rs:

{
	"resource": "[...]/wasm-game-of-life/src/lib.rs",
	"owner": "_generated_diagnostic_collection_name_#1",
	"severity": 8,
	"message": "This operation is unsafe and requires an unsafe function or block",
	"source": "rust-analyzer",
	"startLineNumber": 18,
	"startColumn": 5,
	"endLineNumber": 18,
	"endColumn": 16
}

In this code block the second alert(...) is highlighted:

#[wasm_bindgen]
extern {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(name);
}

However the code compiles regardless.

When changing to:

#[wasm_bindgen]
pub fn greet(name: &str) {
    unsafe{alert(name);}
}

Then I'm getting this warning:

{
	"resource": "[...]/wasm-game-of-life/src/lib.rs",
	"owner": "_generated_diagnostic_collection_name_#1",
	"code": "unused_unsafe",
	"severity": 4,
	"message": "unnecessary `unsafe` block\n`#[warn(unused_unsafe)]` on by default",
	"source": "rustc",
	"startLineNumber": 18,
	"startColumn": 5,
	"endLineNumber": 18,
	"endColumn": 11
}

[jonas-schievink]

That's just because we don't expand procedural macros yet. Presumably it does some magic to make these operations safe.

[dgb23]

That's just because we don't expand procedural macros yet. Presumably it does some magic to make these operations safe.

Would you rather recommend to get the "unsafe" error or the "unused unsafe" warning? Or in other words is my temporary 'fix' the right thing to do or should I just ignore it?

[jonas-schievink]

I'd suggest listening to the rustc warning, not rust-analyzer. If the wrong diagnostics from rust-analyzer annoys you, you can also turn it off in the settings (but this currently turns all of them off).

[kinnison]

I just hit this today myself. Is there a timeline on rust-analyzer being able to run proc-macros?

[bjorn3]

Derive proc macros already work when you enable them. The other kinds are not yet supported. I don't know of any timeline for imolementing this.

[jonas-schievink]

The latest release has preliminary support for function-like procedural macros like foo!();.

Attribute macros are harder to implement and require pretty hairy name resolution changes.

[FermiDirak]

For those looking to disable the missing-unsafe rule until it's fixed and are using VS Code, adding the following to your settings.json and reloading your editor will suppress these errors:

"rust-analyzer.diagnostics.disabled": [
    "missing-unsafe"
]

credit to @popzxc for landing #5682, which makes the above possible

[digama0]

Is it possible to disable these diagnostics locally, using an attribute like with clippy lints?

[jonas-schievink]

Not yet, no

[OliverEvans96]

I just ran into this issue with cxx, which uses macros to generate safe C++ FFIs.

[bjorn3]

You can enable proc-macro support using

{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
}

[OliverEvans96]

Thanks @bjorn3, but unfortunately, that didn't get rid of the erroneous warning. I think I'll stick with disabling missing-unsafe for now.

[lnicola]

@OliverEvans96 cxx also uses attribute proc macros, which are not supported.

[FrankenApps]

You can get rid of this error / warning locally by putting an unsafe block and then surpressing the warning, but it is not a great way to handle that:

#[wasm_bindgen]
pub fn greet(name: &str) {
    #[allow(unused_unsafe)]
    unsafe {
        alert(&format!("Hello, {}!", name));
    }
}

[PanopticaRising]

Just in case anyone doesn't think to check the merged PR and runs into this, I can confirm that I was able to set this in VS Code and got the warning to go away:

    "rust-analyzer.experimental.procAttrMacros": true,

[fosskers]

For folks using Doom Emacs, this seems to do the trick:

(after! lsp-rust
  (setq lsp-rust-analyzer-proc-macro-enable t
        lsp-rust-analyzer-experimental-proc-attr-macros t))

[lnicola]

Recent rust-analyzer versions should have both of those options enabled.