rust-analyzer errors in VSCode with blank project

[maximeborges]

Hi there,
When generating a project I'm getting the following errors in VSCode from rust-analyzer:

I couldn't find a solution to make them go away, is this supposed to be the case or am I missing something there?

I installed the toolchain via espup and also tried a bunch of settings in .vscode/settings.json, like:

{
    "rust-analyzer.server.extraEnv": { "RUSTUP_TOOLCHAIN": "esp"},
    "rust-analyzer.cargo.target": "xtensa-esp32-none-elf",
    "rust-analyzer.checkOnSave": false,
    "rust-analyzer.check.allTargets": false,
    "rust-analyzer.check.overrideCommand": [
        "cargo",
        "clippy",
        "--message-format=json",
        "--bins",
        "--all-features",
        "--target",
        "xtensa-esp32-none-elf",
    ],
    "rust-analyzer.check.targets": "xtensa-esp32-none-elf",
}

[jessebraham]

I've stopped using rust-analyzer with VS Code because I've found it to be basically unusable for embedded projects. It used to be better but over the last year or so it seems to have gotten progressively worse. I have way fewer issues using Emacs, so I assume it's largely to do with the VS Code integration.

I'd actually prefer to remove the .vscode/ directory from this repo altogether.

Sorry, I know this doesn't actually help you. Other than what you've already tried in settings.json I don't really have anything else to suggest.

[1024bees]

FWIW, I've had similar issues when moving from esp-hal-idf to esp-hal. It looks to me like configurations arent being picked up with macros as i am seeing

no method `disable` on type WDT<TIMG0>

and

expected GPIO, found GPIO on a line that reads let io = IO::new(peripherals.GPIO, peripherals.IO_MUX);

I've been toiling with my rust-analyzer config. current reads as:

{
        assist = {
          importMergeBehaviour = "full",
          importPrefix = "plain",
        },

        callInfo = {
          full = true,
        },
        imports = {
          granularity = {
            enforce = true, 
            group = "crate",

          }


        },

        cargo = {
          loadOutDirsFromCheck = true,
          --noDefaultFeatures = true,
          buildScripts = {
            enable = "true"

          }
        },

        checkOnSave = {
          allFeatures = false,
          allTargets = false,
        },

        procMacro = {
          enable = true,
          attributes = {
            enable = true
          }
        },
        diagnostics = {
          enable = true,
          disabled = { "unresolved-proc-macro" },
          enableExperimental = true,
          warningsAsHint = {},
        },
      },

I can give more information if it useful, just trying to see if anyone else has hit this.

[MabezDev]

For me, the esp-template works perfectly. I am running the latest RA with VSCode 1.76.2, no errors and good completion/go to def.

I also tried esp-idf-template which does show an annoying error, but completion and go to def still works.

Not sure what can be done here sounds like issues independent of the esp-rs project.

[1024bees]

I'll look to find a fix for the problem @maximeborges and I are observing and document it in this issue in case it comes up with other devs moving forward.

[1024bees]

After digging through this for a while, it would seem that the issue is that feature flags are not being propegated to build scripts. From rust-analyzer's lsp log:

[ERROR][2023-04-03 23:52:48] .../vim/lsp/rpc.lua:733	"rpc"	"rust-analyzer"	"stderr"	'[ERROR rust_analyzer::main_loop] FetchBuildDataError:
error: One of the feature flags must be provided: esp32, esp32c2, esp32c3, esp32c6, esp32s2, esp32s3, 
  --> build.rs:23:9
   |
23 |         compile_error!(concat!("One of the feature flags must be provided: ", $($all, ", "),*));
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
91 |     assert_unique_used_features!("esp32", "esp32c2", "esp32c3", "esp32c6", "esp32s2", "esp32s3");
   |     -------------------------------------------------------------------------------------------- in this macro invocation
   |
   = note: this error originates in the macro `assert_used_features` which comes from the expansion of the macro `assert_unique_used_features` (in Nightly builds, run with -Z macro-backtrace for more info)


error: aborting due to previous error

error: could not compile `esp-hal-common` (build script) due to 2 previous errors

Funnily enough, this error seems to be agnostic to rust-analyzer setup -- it always occurs, but it only appears to me if

        diagnostics = {
          enable = true,
          disabled = { "unresolved-proc-macro" },
          enableExperimental = true,
          warningsAsHint = {},

is set.

Regardless if this diagnostic is set or not, I cannot go to def on methods that were causing errors in the OP, wdt.disable() for example.

I'll spend a couple days digging on rust-analyzer.

[1024bees]

A few updates -- writing them here to crosspost to rust-analyzer.

Looked at how the workspace is invoked and it looks like the correct features are being propegated to each build script. From my RA log, i can see:

[ERROR][2023-04-09 15:52:27] .../vim/lsp/rpc.lua:733 "rpc" "rust-analyzer" "stderr" '[INFO project_model::build_scripts] /home/james/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-hal-common-0.8.0: BuildScriptOutput { cfgs: [Atom("esp32c3"), Atom("riscv"), Atom("single_core"), Atom("aes"), Atom("apb_ctrl"), Atom("apb_saradc"), Atom("assist_debug"), Atom("dma"), Atom("ds"), Atom("efuse"), Atom("extmem"), Atom("gpio"), Atom("gpio_sd"), Atom("hmac"), Atom("i2c0"), Atom("i2s0"), Atom("interrupt_core0"), Atom("io_mux"), Atom("ledc"), Atom("rmt"), Atom("rng"), Atom("rsa"), Atom("rtc_cntl"), Atom("sensitive"), Atom("sha"), Atom("spi0"), Atom("spi1"), Atom("spi2"), Atom("system"), Atom("systimer"), Atom("timg0"), Atom("timg1"), Atom("twai0"), Atom("uart0"), Atom("uart1"), Atom("uhci0"), Atom("uhci1"), Atom("usb_device"), Atom("xts_aes"), Atom("adc"), Atom("gdma"), Atom("radio"), Atom("phy"), Atom("bt"), Atom("wifi"), Atom("pm_support_wifi_wakeup"), Atom("pm_support_bt_wakeup"), Atom("uart_support_wakeup_int"), Atom("gpio_support_deepsleep_wakeup")], envs: [("OUT_DIR", "/home/james/pf3/target/riscv32imc-unknown-none-elf/debug/build/esp-hal-common-368228cb0a0ab9a4/out")], out_dir: Some(AbsPathBuf("/home/james/pf3/target/riscv32imc-unknown-none-elf/debug/build/esp-hal-common-368228cb0a0ab9a4/out")), proc_macro_dylib_path: None }\n

Looking at the feature flags, it looks like the correct flags are being sent to the build.rs invocation, at least from what project_model::build_scripts is seeing.

I saw that a parallel issue has been raised at rust-lang/rust-analyzer#14452, that seems to match what we're seeing here. The difference between our issue is that I do not see any cyclic deps error message in my RA log, whereas cranelift seems to hit that.

I'll cross post this issue over on rust analyzer to see if they can give any guidance