I'm using a specific Rust nightly build for CS 140E. When I run the commands
rustup default nightly-2018-01-09
rustup component add rust-src
cargo install xargo
I end up with libc failing to build:
error: non-string literals in attributes, or string literals in top-level positions, are experimental (see issue #34981)
--> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.58/src/macros.rs:78:15
It also mentions
= help: add #![feature(attr_literals)] to the crate attributes to enable
Which I've done, which brings me to more complex errors that I have less confidence to fix. Is a nightly build failing in this manner expected? I've also tried rustup default nightly and rustup default stable and they both fail for other reasons.
Related
Windows 10
rustup 1.23.1 (3df2264a9 2020-11-30)
default rustc 1.50.0 (cb75ad5db 2021-02-10)
project rustc 1.52.0-nightly (4a8b6f708 2021-03-11)
rocket = "0.4.4"
I'm trying to build a rust project with rocket but I always get this error when compiling, even after successfully overwriting the project's toolchain:
D:\GitHub\Learning-Rust\poke_api> rustup override set nightly
info: using existing install for 'nightly-x86_64-pc-windows-msvc'
info: override toolchain for 'D:\GitHub\Learning-Rust\poke_api' set to 'nightly-x86_64-pc-windows-msvc'
nightly-x86_64-pc-windows-msvc unchanged - rustc 1.52.0-nightly (4a8b6f708 2021-03-11)
PS D:\GitHub\Learning-Rust\poke_api> cargo build
Compiling winapi v0.3.9
Compiling serde_derive v1.0.124
Compiling rocket v0.4.7
Compiling pear_codegen v0.1.4
Compiling rocket_codegen v0.4.7
Compiling proc-macro2 v1.0.24
Compiling pq-sys v0.4.6
Compiling aho-corasick v0.6.10
Compiling serde_json v1.0.64
error: failed to run custom build command for `pear_codegen v0.1.4`
Caused by:
process didn't exit successfully: `D:\GitHub\Learning-Rust\poke_api\target\debug\build\pear_codegen-e182711746033ac9\build-script-build` (exit code: 101)
--- stderr
Error: Pear requires a 'dev' or 'nightly' version of rustc.
Installed version: 1.48.0 (2020-11-16)
Minimum required: 1.31.0-nightly (2018-10-05)
thread 'main' panicked at 'Aborting compilation due to incompatible compiler.', C:\Users\gabre\.cargo\registry\src\github.com-1ecc6299db9ec823\pear_codegen-0.1.4\build.rs:24:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
I had a similar issue while using rocket. Same error message too, Error: Pear requires a 'dev' or 'nightly' version of rustc.
If you get to the get-started page on rocket framework website. It says, "Rocket makes abundant use of Rust's syntax extensions and other advanced, unstable features. Because of this, we'll need to use a nightly version of Rust."
My issue was I was not using a nightly version of rust. Running this on my terminal in my project directory did it for me.
rustup override set nightly
If you check the cargo version for that directory after,
cargo version
you will confirm it has switched to nightly version
Failed compilation even with nightly
It looks like you have some outdated dependencies (pear-codegen probably being the one that causes trouble), updating these may resolve the compilation issues.
General notes on how to override the toolchain
Using rustups override works fine, but it is bound to your local rustup configuration and not specified inside the project.
In order to achieve this, thereby making the project more portable and allowing others to always use the correct toolchain, I would recommend the toolchain file. It can look something like this (example taken from linked page) and will accurately specify the required toolchain only for the containing project.
# rust-toolchain.toml
[toolchain]
channel = "nightly-2020-07-10"
components = [ "rustfmt", "rustc-dev" ]
targets = [ "wasm32-unknown-unknown", "thumbv2-none-eabi" ]
profile = "minimal"
For your purposes a simple configuration like this will most likely be all you need, although adding the components you want to use would be beneficial.
[toolchain]
channel = "nightly"
My issue was with rust-analyser that wouldn't start because multiple rocket dependencies needed nightly or dev version of rustc.
These steps fixed my issue:
Switch to nightly for my rocket project by running rustup override set nightly inside the app folder.
Remove all target folders in my project. (I also had one in root)
Manually remove the faulty cached packages from cargo cache. cd ~/.cargo/registry/cache/github.com-xxxxxxxxxxxx && rm -r pear_codegen-0.1.5/
The output of rustup target list --toolchain nightly does not contain x86_64-apple-ios-macabi, even though it is in src/librustc_target on the Rust master branch.
How do I build for Mac Catalyst / x86_64-apple-ios-macabi?
The x86_64-apple-ios-macabi target is available on the nightly (5c5b8afd8 2019-11-16) compiler. Just because a target is available does not mean that the standard library and friends are compiled or available to rustup:
% rustc +nightly --print target-list | grep macabi
x86_64-apple-ios-macabi
Rust has a tier system (which is the subject of a proposed RFC). This target is so new it's not even listed on the tier list, but it's undoubtedly going to be tier 3. Tier 2.5 says (emphasis mine):
Tier 2.5 platforms can be thought of as "guaranteed to build", but without builds available through rustup
In the meantime, you will need to build your own libcore / libstd from source. I don't have the time nor ability to actually test that the compilation works, but something like these choices are the general starting path:
build-std
The unstable -Z build-std flag can be used to build the standard library:
% cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi
Xargo
Building the standard library can be done using the xargo tool.
% rustup override set nightly
info: using existing install for 'nightly-x86_64-apple-darwin'
info: override toolchain for '/private/tmp/example' set to 'nightly-x86_64-apple-darwin'
nightly-x86_64-apple-darwin unchanged - rustc 1.41.0-nightly (5c5b8afd8 2019-11-16)
% cat > Xargo.toml
[target.x86_64-apple-ios-macabi.dependencies.std]
# features = ["jemalloc"] # Whatever is appropriate
% xargo build --target x86_64-apple-ios-macabi
# Iterate until libcore and libstd compile and work for your platform
#shepmaster 's answer is correct. In detail, you have to:
Install Xargo:
cargo install xargo
cd in your project
use the nighly build:
rustup override set nightly
create the Xargo.toml file with content:
[target.x86_64-apple-ios-macabi.dependencies.std]
In your projects Cargo.toml, make sure the [profile.release] section contains panic = "abort". If it does not, add it.
When building the project, use xargoinstead of cargo.
Shepmaster's answer is a little outdated. Cargo now supports the -Zbuild-std command. Using it, you can target any of the targets that rustc itself supports even if they aren't listed on rustup +nightly target list. Simply:
rustc +nightly --print target-list
and
cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi
should be enough now. You don't need xargo to build the standard lib anymore.
If you have an old installation of rust, you might need to remove old nightly (or at least for me it fails to update nightly):
rustup toolchain remove nightly
rustup update
rustup toolchain install nightly
Is it possible to run cargo clippy with an option so it will fix warnings automatically?
From the help message, it does not look like this option is supported at the moment.
As of June 2021 the autofix capability has been stabilized, you can apply changes using the following command
cargo clippy --fix
cargo fix can already apply some suggestions deriving from rustc's errors and warnings.
In nightly builds you can use cargo clippy --fix to apply some suggestions from Clippy. In some older Rust versions, the syntax is reversed: cargo fix --clippy.
If you are using a stable version of the Rust toolchain, you can opt-in to use a nightly build for just one command, by using +nightly to override the toolchain:
cargo +nightly clippy --fix -Z unstable-options
I'm trying to run my tests with nightly Rust using Windows Powershell. I run cargo test in the directory, and I get
Compiling rustcraft v0.1.0 (file:///C:/Users/Phoenix/Desktop/Rust/rustcraft)
error[E0554]: #![feature] may not be used on the stable release channel
--> C:\Users\Phoenix\Desktop\Rust\rustcraft\src\main.rs:1:1
|
1 | #![feature(integer_atomics)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0554]: #![feature] may not be used on the stable release channel
--> C:\Users\Phoenix\Desktop\Rust\rustcraft\src\main.rs:2:1
|
2 | #![feature(collections)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
Obviously, I have to tell Cargo to compile it on the nightly channel, but how? I can't find any reference to specifying a channel in the help section, or any website I've found.
The command line solution may help you to configure your IDE:
cargo +nightly test
Provided, of course, that you have the nightly channel installed. If not, perhaps install it with rustup install nightly (no need to switch to it, but check you're still on stable: rustup show).
The +<toolchain> functionality comes from rustup, the Rust toolchain manager. It works for both cargo +<toolchain> as well as rustc +<toolchain>.
In addition, you can use
rustup run <toolchain> <any arbitrary command goes here>
Since your project requires nightly features, you can change into the directory and run rustup override set <toolchain> to always use the nightly toolchain in that directory.
Create a file called rust-toolchain in your directory containing the name of the toolchain required (e.g. nightly). This has the safe effect as an override, but can be committed to source control.
See also:
Is it possible to have multiple coexisting Rust installations?
When using serde in stable as recommended by the respective blog post, one will have to use the built-in include! macro to pull in a file generated by serde-codegen.
The file linked here shows this in a more complex example which can use rustc nightly as well as rustc stable.
However, as the docs of include! suggest, it does not behave hygienically.
What this means was unclear to me until I ran into the issue that macros defined in an external crate, yup-hyper-mock, were not defined at include-time. Some tests showed that even something like extern crate foo-bar-snoo-snoo; will not trigger an error at include-time, showing that it was not yet evaluated at all.
The problem arises from include! trying to expand macros, and failing if these are coming from external crates which haven't been evaluated yet.
An attempt of mine to define empty macros with the correct signature cause the include! macro to work, but the compile would fail later as include! would actually expand the macro right away, which was empty at the time of the include.
Is there a way to make include! work with macros defined in external crates? Alternatively, can you imagine a workaround to make my particular case work?
Personally I think include! should not expand macros at all, but leave that to the next compile step which should bring in external crates - maybe we are looking at a bug in rustc, but I am not sure about that.
How to reproduce
Please note that both stable and nightly compilers show the same issues.
git clone --branch syntex https://github.com/Byron/yup-oauth2
cd yup-oauth2
git reset --hard f59d97d
# build and test fail because 'include!' runs before crates are pulled
# in, but still expands macros
cargo build
cargo test
Meta
stable
➜ yup-oauth2 git:(syntex) rustc --version --verbose
rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14)
binary: rustc
commit-hash: a59de37e99060162a2674e3ff45409ac73595c0e
commit-date: 2015-05-13
build-date: 2015-05-14
host: x86_64-apple-darwin
release: 1.0.0
nightly
➜ yup-oauth2 git:(syntex) rustc --version --verbose
rustc 1.2.0-nightly (2228ce10c 2015-06-09)
binary: rustc
commit-hash: 2228ce10c6d83c17b6346396aa7c7ef9082f1c04
commit-date: 2015-06-09
host: x86_64-apple-darwin
release: 1.2.0-nightly