IntelliJ Rust plugin can't build runtime #6247

nazar-pc · 2024-10-26T19:50:36Z

Is there an existing issue?

I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

This is not a support question.

Description of bug

I'm getting the following confusing error:

error: failed to run custom build command for `pallet-revive-fixtures v0.1.0 (/web/subspace/polkadot-sdk/substrate/frame/revive/fixtures)`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.
Caused by:
  process didn't exit successfully: `/home/nazar-pc/.cache/cargo/target/debug/build/pallet-revive-fixtures-aff745ce5f9ef36b/build-script-build` (exit status: 1)
  --- stdout
  cargo::rerun-if-changed=/web/subspace/polkadot-sdk/substrate/frame/revive/fixtures
  cargo::rerun-if-changed=/web/subspace/polkadot-sdk/substrate/frame/revive/uapi
  --- stderr
      Updating crates.io index
       Locking 13 packages to latest compatible versions
        Adding bitflags v1.3.2 (latest: v2.6.0)
    Downloaded polkavm-derive v0.13.0
    Downloaded polkavm-derive-impl-macro v0.13.0
    Downloaded polkavm-derive-impl v0.13.0
  error: "/home/nazar-pc/.rustup/toolchains/rve-nightly/lib/rustlib/src/rust/library/Cargo.lock" does not exist, unable to build with the standard library, try:
          rustup component add rust-src --toolchain rve-nightly
  Error: Failed to build contracts
  Stack backtrace:
     0: anyhow::error::<impl anyhow::Error>::msg
     1: anyhow::__private::format_err
     2: build_script_build::build::invoke_build
     3: build_script_build::build::run
     4: build_script_build::main
     5: core::ops::function::FnOnce::call_once
     6: std::sys::backtrace::__rust_begin_short_backtrace
     7: std::rt::lang_start::{{closure}}
     8: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ops/function.rs:284:13
     9: std::panicking::try::do_call
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:554:40
    10: std::panicking::try
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:518:19
    11: std::panic::catch_unwind
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panic.rs:345:14
    12: std::rt::lang_start_internal::{{closure}}
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/rt.rs:143:48
    13: std::panicking::try::do_call
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:554:40
    14: std::panicking::try
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:518:19
    15: std::panic::catch_unwind
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panic.rs:345:14
    16: std::rt::lang_start_internal
               at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/rt.rs:143:20
    17: std::rt::lang_start
    18: main
    19: __libc_start_call_main
               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    20: __libc_start_main_impl
               at ./csu/../csu/libc-start.c:360:3
    21: _start

The lock file exists for me, but at /home/nazar-pc/.rustup/toolchains/rve-nightly/lib/rustlib/src/rust/Cargo.lock instead. Not sure why it is searching for lock file at the wrong location.

I have rve-nightly 1.1.0 installed.

Steps to reproduce

No response

The text was updated successfully, but these errors were encountered:

acatangiu · 2024-10-28T08:05:03Z

cc @pgherveou @xermicus

JuaniRios · 2024-10-29T12:37:50Z

Have the same problem

ggwpez · 2024-10-29T13:06:32Z

Is that enabling all features by any chance? Enabling the RISCV feature will cause it to fail compiling, since you probably dont have that toolchain.

nazar-pc · 2024-10-29T13:07:46Z

I do have the toolchain though, see rve-nightly in the original message, is that not it?

pgherveou · 2024-10-29T13:15:59Z

which runtime are you trying to build, this should only build if you specify riscv?
Is that just intellij or building from the command line fails for you as well?

This should merge soon, does it fix your error #6266

nazar-pc · 2024-10-29T13:18:08Z

Just opening project in IDE, it tries to build and analyze everything and fails. Have not tried the mentioned PR and working on something else at the moment.

xermicus · 2024-10-29T13:23:29Z

#6266 will fix this.

What exactly are you trying to do? The custom toolchain is only required for developing the revive pallet. A correct configuration shouldn't pass the riscv feature around.

nazar-pc · 2024-10-29T13:26:27Z

As said above, I try to open a project in IDE. During this IDE will build and expand macros in the whole codebase to build whatever information it needs about the project to enable various IDE features like refactoring, etc.

So revive is nothing special, it'll be built just like everything else.

xermicus · 2024-10-29T13:33:04Z

Ah okay, my web UI didn't reload above comments 😅

Yeah this used to work but broke for some reason. I can repro locally, but #6266 will fix it.

athei · 2024-10-29T14:57:19Z

Did intellij worked for you properly before? In my experience it never worked really well on that repo. Not saying we should not resolve this issue. But probably something else will pop up after fixing it.

nazar-pc · 2024-10-29T15:11:55Z

It worked in the past and other than this still works.

At the same time there are some annoying things about how this repo is maintained, so I have to use environment variables to set one toolchain version for checking the code and another for formatting purposes. And #5317 that would fix at least one half of that is yet to be merged.

athei · 2024-10-31T13:16:14Z

Should be fixed by #6305

Can you confirm?

nazar-pc · 2024-10-31T13:30:12Z

Actually no, at very least it complains about -Z only available on nightly compiler, while the repo is supposed to be built with a stable compiler.

athei · 2024-10-31T13:33:51Z

This is why we setting this:

polkadot-sdk/substrate/frame/revive/fixtures/build.rs

Line 121 in dd9924f

.env("RUSTC_BOOTSTRAP", "1")

Building this with cargo works. It seems that intellij is ignoring this somehow. Or it prefilters the CLI args and comes to the conclusion that it won't work when in fact it actually does.

I suggest setting a nightly toolchain in intellij to fix that. Or file a bug with them.

The alternative would be to have the build script use nightly instead of the outer toolchain. But I am not sure if that would fix intellij.

nazar-pc · 2024-10-31T14:06:07Z

This is why we setting this:

That is a dirty hack, no one except Rustc itself should really use RUSTC_BOOTSTRAP=1. I believe it is also not guaranteed to be stable by any means, so might compile with one "stable" version and not compile with another.

I suggest setting a nightly toolchain in intellij to fix that

I wish I could, but then I get lots of false-positive from additional clippy lints triggered on Substrate codebase all over the place and when I run cargo clippy in the terminal it'll be recompiling everything from scratch after IDE compiled things with a different toolchain.

It is really a huge pain to work with for contributors without rust-toolchain.toml in the repo.

Here is what IDE spits out:

error: failed to run custom build command for `sc-runtime-test v2.0.0 (/web/subspace/polkadot-sdk/substrate/client/executor/runtime-test)`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.
Caused by:
  process didn't exit successfully: `/home/nazar-pc/.cache/cargo/target/debug/build/sc-runtime-test-6b0fe188e2cd6525/build-script-build` (exit status: 1)
  --- stdout
  cargo:warning=Could not find `Cargo.lock` for `/web/subspace/polkadot-sdk/substrate/client/executor/runtime-test/Cargo.toml`, while searching from `/home/nazar-pc/.cache/cargo/target/debug/build/sc-runtime-test-7d6304c2b671cf30/out`. To fix this, point the `WASM_BUILD_WORKSPACE_HINT` env variable to the directory of the workspace being compiled.
  cargo:warning=Could not find `Cargo.lock` for `/web/subspace/polkadot-sdk/substrate/client/executor/runtime-test/Cargo.toml`, while searching from `/home/nazar-pc/.cache/cargo/target/debug/build/sc-runtime-test-7d6304c2b671cf30/out`. To fix this, point the `WASM_BUILD_WORKSPACE_HINT` env variable to the directory of the workspace being compiled.
  Information that should be included in a bug report.
  Executing build command: env -u CARGO_ENCODED_RUSTFLAGS -u RUSTC CARGO_MAKEFLAGS="-j --jobserver-fds=8,9 --jobserver-auth=8,9" CARGO_TARGET_DIR="/home/nazar-pc/.cache/cargo/target/debug/wbuild/sc-runtime-test/target" RUSTC_BOOTSTRAP="1" RUSTFLAGS="-C target-cpu=mvp -C target-feature=-sign-ext -C link-arg=--export-table -Clink-arg=--export=__heap_base -C link-arg=--import-memory  --cfg substrate_runtime " SKIP_WASM_BUILD="" "/home/nazar-pc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo" "rustc" "--target=wasm32-unknown-unknown" "--manifest-path=/home/nazar-pc/.cache/cargo/target/debug/wbuild/sc-runtime-test/Cargo.toml" "--color=always" "--profile" "release" "-Z" "build-std"
  Using rustc version: rustc 1.82.0 (f6e511eec 2024-10-15)
  --- stderr

athei · 2024-10-31T14:36:49Z

That is a dirty hack, no one except Rustc itself should really use RUSTC_BOOTSTRAP=1. I believe it is also not guaranteed to be stable by any means, so might compile with one "stable" version and not compile with another.

So is using a nightly toolchain. We are using an unstable feature. Of course it doesn't get stable by using a stable toolchain. However, it improves the experience as people don't need to install an additional toolchain.

It is really a huge pain to work with for contributors without rust-toolchain.toml in the repo.

This rust-toolchain.toml would need to contain a nightly toolchain, though.

pgherveou · 2024-10-31T15:37:50Z

@nazar-pc
did you try what is suggested by the error message here

error: "/home/nazar-pc/.rustup/toolchains/rve-nightly/lib/rustlib/src/rust/library/Cargo.lock" does not exist, unable to build with the standard library, try:
          rustup component add rust-src --toolchain rve-nightly
  Error: Failed to build contracts

athei · 2024-10-31T15:38:45Z

Nahh. We are building with the toolchain used to build the crate now. So the rust-src component has to be installed for that.

nazar-pc · 2024-10-31T15:44:40Z

did you try what is suggested by the error message here

As I wrote in the very first message, it was already installed

athei · 2024-10-31T16:06:20Z

Are you sure? You only state the rve-nightly toolchain is installed. What we ask you to do is to install rust-src for whatever toolchain you are building the workspace with.

nazar-pc · 2024-10-31T16:18:03Z

I do have rust-src component installed as well (which rust-toolchain.toml #5317 would ensure as well)

nazar-pc · 2024-11-04T17:02:35Z

On latest master regular build in CLI with cargo +1.81.0 check --all-targets --workspace now fails too:

error: failed to run custom build command for `pallet-revive-fixtures v0.1.0 (/web/subspace/polkadot-sdk/substrate/frame/revive/fixtures)`

Caused by:
  process didn't exit successfully: `/home/nazar-pc/.cache/cargo/target/debug/build/pallet-revive-fixtures-4243b16f4f2a1323/build-script-build` (exit status: 1)
  --- stdout
  cargo::rerun-if-env-changed=PALLET_REVIVE_FIXTURES_RUSTUP_TOOLCHAIN
  cargo::rerun-if-env-changed=PALLET_REVIVE_FIXTURES_STRIP
  cargo::rerun-if-env-changed=PALLET_REVIVE_FIXTURES_OPTIMIZE
  cargo::rerun-if-changed=/web/subspace/polkadot-sdk/substrate/frame/revive/fixtures
  cargo::rerun-if-changed=/web/subspace/polkadot-sdk/substrate/frame/revive/uapi

  --- stderr
      Updating crates.io index
       Locking 13 packages to latest compatible versions
        Adding bitflags v1.3.2 (latest: v2.6.0)
   Downloading crates ...
    Downloaded syn v2.0.87
  error: "/home/nazar-pc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/Cargo.lock" does not exist, unable to build with the standard library, try:
          rustup component add rust-src

  Error: Failed to build contracts

Two problems here.

Wrong lock file path:

-.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/Cargo.lock
+.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/Cargo.lock

The path used is actually correct for 1.81.0, but not for 1.82.0 (current stable).

The reason it has the wrong path is likely related to the fact that if you look closely it is stable, not 1.81.0 that I specified for cargo explicitly, so it only really works properly in CI or environments where it is configured as the only (default?) version. I think fixing it will fix the issue here.

athei · 2024-11-05T08:06:21Z

So you think what is going wrong is that the build.rs is selecting stable instead of 1.81 as it should? If this is true it should be fixed by adding rust-src to 1.81? Can you try? Will still need to fix the version selection. This is just to confirm.

athei · 2024-11-05T11:25:32Z

I am trying to reproduce and fix that.

athei · 2024-11-05T11:54:57Z

I was able to reproduce. Should be fixed by: #6365

athei · 2024-11-05T18:39:28Z

Can you confirm if your problem if fixed?

nazar-pc · 2024-11-05T19:00:43Z

Building with CLI is fixed indeed, but IDE is still broken. Here is full log with everything IDE does and how (note it runs with 1.82.0 stable, which is my default):
intellij-rust.log

athei · 2024-11-05T21:12:59Z

As said before: We can't fix it on our end. Intellij seems to ignore RUSTC_BOOSTRAP and requires a nightly toolchain. You can probably fix it on your end by setting a nightly toolchain for your polkadot-sdk. Or by just selecting a nightly toolchain for intellij.

nazar-pc · 2024-11-05T21:46:48Z

Tried to reproduce in the terminal and wasn't able, reported upstream: https://youtrack.jetbrains.com/issue/RUST-16254/Building-polkadot-sdk-in-IDEA-fails

nazar-pc added I10-unconfirmed Issue might be valid, but it's not yet known. I2-bug The node fails to follow expected behavior. labels Oct 26, 2024

nazar-pc closed this as not planned Won't fix, can't repro, duplicate, stale Nov 5, 2024

niklasad1 mentioned this issue Dec 2, 2024

Subxt integration tests failed against latest Substrate build. paritytech/subxt#1876

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

IntelliJ Rust plugin can't build runtime #6247

IntelliJ Rust plugin can't build runtime #6247

nazar-pc commented Oct 26, 2024

acatangiu commented Oct 28, 2024

JuaniRios commented Oct 29, 2024

ggwpez commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

pgherveou commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

xermicus commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

xermicus commented Oct 29, 2024

athei commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

athei commented Oct 31, 2024

nazar-pc commented Oct 31, 2024

athei commented Oct 31, 2024 •

edited

Loading

nazar-pc commented Oct 31, 2024

athei commented Oct 31, 2024

pgherveou commented Oct 31, 2024

athei commented Oct 31, 2024

nazar-pc commented Oct 31, 2024

athei commented Oct 31, 2024

nazar-pc commented Oct 31, 2024

nazar-pc commented Nov 4, 2024

athei commented Nov 5, 2024

athei commented Nov 5, 2024

athei commented Nov 5, 2024 •

edited

Loading

athei commented Nov 5, 2024

nazar-pc commented Nov 5, 2024 •

edited

Loading

athei commented Nov 5, 2024

nazar-pc commented Nov 5, 2024

IntelliJ Rust plugin can't build runtime #6247

IntelliJ Rust plugin can't build runtime #6247

Comments

nazar-pc commented Oct 26, 2024

Is there an existing issue?

Experiencing problems? Have you tried our Stack Exchange first?

Description of bug

Steps to reproduce

acatangiu commented Oct 28, 2024

JuaniRios commented Oct 29, 2024

ggwpez commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

pgherveou commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

xermicus commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

xermicus commented Oct 29, 2024

athei commented Oct 29, 2024

nazar-pc commented Oct 29, 2024

athei commented Oct 31, 2024

nazar-pc commented Oct 31, 2024

athei commented Oct 31, 2024 • edited Loading

nazar-pc commented Oct 31, 2024

athei commented Oct 31, 2024

pgherveou commented Oct 31, 2024

athei commented Oct 31, 2024

nazar-pc commented Oct 31, 2024

athei commented Oct 31, 2024

nazar-pc commented Oct 31, 2024

nazar-pc commented Nov 4, 2024

athei commented Nov 5, 2024

athei commented Nov 5, 2024

athei commented Nov 5, 2024 • edited Loading

athei commented Nov 5, 2024

nazar-pc commented Nov 5, 2024 • edited Loading

athei commented Nov 5, 2024

nazar-pc commented Nov 5, 2024

athei commented Oct 31, 2024 •

edited

Loading

athei commented Nov 5, 2024 •

edited

Loading

nazar-pc commented Nov 5, 2024 •

edited

Loading