rust-analyzer: Unknown types in web-sys dependency

(I suspect this is a duplicate, but i’m not sure what the root cause is).

I’m trying to use the web-sys crate, which is highly generated.

I’ve enabled both loadOutDirsFromCheck and procMacro.enable:

.vscode/settings.jon

{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
    "editor.tokenColorCustomizationsExperimental": {
        "unresolvedReference": "#FF0000"
    }
}

Cargo.toml

[package]
name = "foo"
version = "0.1.0"
authors = ["Andrew Chin <achin@eminence32.net>"]
edition = "2018"

[dependencies.web-sys]
version = "0.3"
features = ["Document", "Window"]

Code:

use web_sys::{Document, Window};

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

Using RA nightly (fe99a29)

Thanks!

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 2
Comments: 31 (29 by maintainers)

Most upvoted comments

That PR has landed. But that didn’t help web-sys much. If web-sys was using genuine extern opaque type syntax as input to macros (e.g. impl blocks etc) the issue would have been solved. It seems we need to improve proc macro support next. I’ll look into what i can do to help.

+14

crlf0710 on Sep 17, 2020

I gave adding support for extern opaque types a try in https://github.com/rust-analyzer/rust-analyzer/pull/5993 .

crlf0710 on Sep 16, 2020

I think 90% proper fix would be to allow proc macro authors to annotate their macros as “this doesn’t change item semantics”, so that we know that the treatment, suggested above, is fully correct.

I’m not sure we can do this in a useful way? For example, it seems wasm_bindgen(start) on a function doesn’t change the function, but wasm_bindgen on other items has noticeable effects. We could maybe notice that the macro didn’t actually change the function though?

flodiebold on Sep 2, 2021