For some reason Rust Analyzer isn't generating a warning for undefined variables. Do I need to tweak some settings somewhere?
I'm also not getting warnings for unused variables, unimported crates, etc.
Edit: Tested this out with a new workspace. Both cargo check and Rust Analyzer work. It reports a single intentional error. When I run cargo check in the first workspace, it reports a lot of errors in the ~/.cargo directory, and none in the current workspace. Perhaps a crate I am using has errors and is locking up cargo check before it can get around to checking the files in my directory?
The log when running cargo check showed some issues with ~/.cargo/registry/src/github.com-xx..xx/rppal-0.12.0. This came from a the crate rust_gpiozero that I had listed as a dependency. As best as I can figure, cargo check was failing on this and then ceasing to analyze my files. After removing this dependency, both cargo check and Rust Analyzer run as expected.
Cheers to all who replied to this thread for their guidance.
Rust-analyzer itself doesn't produce errors or warnings for this.
If you want warnings and errors, enable the "Check on Enable" option in the rust-analyzer extension. This will run cargo check every time you save a Rust file and display the emitted warnings and errors in the files.
For another possible cause: try cargo clean.
This problem happened to me after upgrading my toolchain version. As mentioned in other answers, running cargo check yielded many errors. The topmost error mentioned a crate "compiled by an incompatible version of rustc." Running cargo clean followed by cargo check fixed all errors.
Related
I work on a Rust project that has a lot of packages as explicit or implicit dependencies (~420). When I want to rebuild the target after changing the .env file (that configures things like IP to download files from), I would like to rebuild only the packages that I authored, not all the dependencies.
How can I tell cargo build to use the previously compiled dependencies, but not use the previously compiled package that uses the .env file as input?
Ideally, cargo build would realize that the .env file has changed and automatically decide to rebuild only the parts that use the .env file, but unfortunately this doesn't seem to be the case.
So the second best solution is to manually tell cargo build at which point in the build graph to start off again.
We're using the dotenv crate https://crates.io/crates/dotenv crate to read the .env file.
I tried cargo clean -p nextclade to tell it to clean only the package in question that I'm working on - but that still cleans up all the dependencies which cause my build to take 5 minutes rather than 2 minutes (if using compiled dependencies).
There's a question that seems to ask a similar question, but that question is actually a different use case/set up, so it's not a duplicate: How does cargo decide whether to rebuild the deps or not?
I followed the tutorialenter link description here to this step，
make build
WASM_BUILD_TOOLCHAIN=nightly-2020-10-05 cargo build --release
Compiling node-template-runtime v2.0.0 (/home/wangliqiu2021/CLionProjects/substrate-node-template/runtime)
Building [=====================================================> ] 857/861: node-template-runtime(build)
Cargo has been executed for a long time(almost one+ hour) without ending,It seems to be stuck, does anyone know the reason？help me
OS：Ubuntu 20.04
CPU: AMD Ryzen 7 1700 Eight-Core Processor
The compile is not stuck in compilation, it is just taking a while due to the 800+ dependencies. From #gnunicorn on this github issue:
Rust isn't particular quick with the compiling at the moment and opaque to the person in front, at this step (when compiling node-template-runtime) we are actually building the project twice: once natively and once in wasm. So at some step in between it appears as if nothing happens and that can take up to half the total build time – if the other part took e.g. 10minutes then this process might take another 10min without any indicator of process (other than the CPU pumping hard).
You are doing a release build (cargo build --release) which enables optimizations. For development purposes, a regular build or just a cargo check will be substantially faster.
Some comments in the linked GitHub issue mentioned that running a cargo clean and rebuilding helped speed up compile times, so you can try that as well.
From your username. I think you are in China, same as me.
node-template-runtime(build) means you're compiling the runtime into a wasm file. During this, it might need a download (so try to use a VPN).
The download only happened in 1.0.0 https://docs.rs/substrate-wasm-builder/1.0.0/substrate_wasm_builder/?search=
Also, the wasm compiling will take a long time too (depend on your hardware).
In the 2016 MacBookPro, the whole compiling takes 30mins.
Moreover, there might be a bug in that build.rs. Sometimes I've to run cargo clean. If I interrupt the compiling while node-template-runtime(build).
I found the reason.
$CARGO_HOME/config.toml:
[build]
target-dir = "target"
remove it.
In my case the issue was, that the WASM runtime build expects to find the WASM files inside the local target directory.
If the build can't find the local WASM files in the target directory - it just hangs or deadlocks (e.g. GitHub issue).
I had to change the target-dir setting in ~/.cargo/config.toml.
You can also override the global setting with a local env var:
CARGO_TARGET_DIR=target cargo build
Or you can use the cargo CLI flags:
cargo build --target-dir=target
Note that some of the wasm-builder based build scripts ignore the CARGO_TARGET_DIR env variable (e.g. wasm_project.rs).
I have a project using Rust nightly with logos 0.11.4 as a dependency. When I run cargo build, I get
error: failed to download `logos v0.11.4`
Caused by:
unable to get packages from source
Caused by:
failed to parse manifest at `C:\Users\jonat\.cargo\registry\src\github.com-1ecc6299db9ec823\logos-0.11.4\Cargo.toml`
Caused by:
readme file with name '../README.md' was not found
It turns out that logos has a nested package called logos-derive, and the Cargo.toml for this project has the line readme = "../README.md". In other words, it's pointing to the README from the parent directory. However, the Cargo source registry places the logos-0-11.4 and logos-derive-0.11.5 directories at the same level, rather than nesting them, which explains why the file is not found. I can actually get it to build by creating an empty .cargo/registry/src/github.com-1ecc6299db9ec823/README.md. But that's obviously not a satisfactory long-term fix.
Note that I was able to build just fine two days ago (2020-06-11), but despite there not being any changes to logos or logos-derive in that time, I'm now unable to build - even after checking out my project from that time and downgrading my toolchain to nightly-2020-06-11. I'm not sure how that's possible or what in my build process has changed.
Am I doing something wrong, is logos-derive doing something wrong, or has Cargo changed something recently? Anyone have a proper solution?
The issue seems to have mysteriously disappeared again in nightly-2020-06-13. I don't know what the cause was, but I guess this is resolved.
I'm trying to build a Rust project (xray). When running cargo run I get the following error message
error: manifest path D:\xray\building\xray\Cargo.toml is a virtual
manifest, but this command requires running against an actual package
in this workspace
What exactly does this mean and how can it be solved? I'm using Cargo version 0.25.0 and Rust version 1.24.1.
Your Cargo.toml is a virtual manifest.
In workspace manifests, if the package table is present, the workspace root crate will be treated as a normal package, as well as a workspace. If the package table is not present in a workspace manifest, it is called a virtual manifest.
When working with virtual manifests, package-related cargo commands, like cargo build, won't be available anymore. But, most of such commands support the --all option, will execute the command for all the non-virtual manifest in the workspace.
cargo run does not work, because cargo doesn't know what to run. There are two options:
--manifest-path <PATH>: Path to Cargo.toml of the crate you want to run.
-p, --package <SPEC>: Package you want to run.
In your case it's probably cargo run --package xray_cli
the manifest has both package and workspace sections can't works. please check the Cargo.toml and remove package from it.
Virtual Manifest is new concepts, please reading docs to familiar it. Hope it values for you.
Several builds, like this one, fail when executing cabal check:
++cabal check
These warnings may cause trouble when distributing the package:
* 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
and not just imposing longer compile times on your users.
However, most of the other builds in the matrix do not fail after this check.
I'm using the complex Travis configuration suggested at the stack docs, and this is the Travis configuration specific for the project I'm trying to get on CI.
Any ideas on what might be causing this behavior?
There are two types of build in your travis config:
Stack based build
Cabal based build
If you follow the script code, you will see that only Cabal based build has the command cabal check in it. That will explain why all of your Stack based builds are working fine. Now, let's see the cabal check command line in detail:
cabal check || [ "$CABALVER" == "1.16" ]
So, if your installed cabal version is 1.16, it will ignore the output of cabal check and that command is treated as a success. And infact, that's what is happening. Only one Cabal based build job is success in your travis, because it's version is 1.16.