"#![feature] may not be used on the stable release channel"

[silmeth]

When starting a brand new project and adding anyhow = "1.0" or anyhow = "=1.0.60" to the dependencies, the build/check fails with:

% cargo check
    Checking anyhow v1.0.60
error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /home/silmeth/.cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.60/src/lib.rs:214:32
    |
214 | #![cfg_attr(backtrace, feature(backtrace))]
    |                                ^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `anyhow` due to previous error
zsh: exit 101   cargo check

It passes with anyhow = "=1.0.59" though.

Using:

% rustc --version
rustc 1.62.1 (e092d0b6b 2022-07-16)

[lseelenbinder]

Confirming this issue.

[dtolnay]

There are two changes between 1.0.59 and 1.0.60. Could you try these two and report which one reproduces the issue?

[dependencies]
anyhow = "1.0.59"

[patch.crates-io]
anyhow = { git = "https://github.com/dtolnay/anyhow", rev = "abe9d3c429c0df113c52fd0ee5b074402746f50b" }

[dependencies]
anyhow = "1.0.59"

[patch.crates-io]
anyhow = { git = "https://github.com/dtolnay/anyhow", rev = "5fbf4eda3a9e7392f00fbb4ccaa216a108025f64" }

[silmeth]

Hmm, both revisions build without problems:

silmeth@silmeth-desktop:/tmp/anyhow-test% cargo check
    Updating git repository `https://github.com/dtolnay/anyhow`
   Compiling anyhow v1.0.59 (https://github.com/dtolnay/anyhow?rev=abe9d3c429c0df113c52fd0ee5b074402746f50b#abe9d3c4)
    Checking anyhow-test v0.1.0 (/tmp/anyhow-test)
    Finished dev [unoptimized + debuginfo] target(s) in 0.81s

### changed Cargo.toml here

silmeth@silmeth-desktop:/tmp/anyhow-test% cargo check
    Updating git repository `https://github.com/dtolnay/anyhow`
    Updating crates.io index
   Compiling anyhow v1.0.59 (https://github.com/dtolnay/anyhow?rev=5fbf4eda3a9e7392f00fbb4ccaa216a108025f64#5fbf4eda)
    Checking anyhow-test v0.1.0 (/tmp/anyhow-test)
    Finished dev [unoptimized + debuginfo] target(s) in 1.59s

[Razican]

1.0.60 builds correctly with Rust 1.62.1 (stable): https://github.com/boa-dev/boa/runs/7662862271?check_suite_focus=true

If the backtrace feature is not active, of course.

[RalfJung]

When starting a brand new project and adding anyhow = "1.0" or anyhow = "=1.0.60" to the dependencies, the build/check fails with:

I cannot reproduce this, is there anything else in your setup that might affect this? Could you share the full Cargo.toml of your new project? This works for me:

[package]
name = "anytest"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
anyhow = "=1.0.60"

[patch.crates-io]
anyhow = { git = "https://github.com/dtolnay/anyhow", rev = "e55761e27b05de6d5f9dc583285d26cf77831fba" }

Also please share your verbose version information:

$ rustc --version -v
rustc 1.62.1 (e092d0b6b 2022-07-16)
binary: rustc
commit-hash: e092d0b6b43f2de967af0887873151bb1c0b18d3
commit-date: 2022-07-16
host: x86_64-unknown-linux-gnu
release: 1.62.1
LLVM version: 14.0.5

Do you have the RUSTC or RUSTC_WRAPPER env var set?

[silmeth]

RUSTC and RUSTC_WRAPPER are empty:

silmeth@silmeth-desktop:/tmp/anyhow-test% echo $RUSTC

silmeth@silmeth-desktop:/tmp/anyhow-test% echo $RUSTC_WRAPPER

But I now cannot reproduce this anymore either. I don’t know what happened. I created a new empty project, then added anyhow = "1.0" and some other dependencies, among them tokio = { version = "1.0", features = ["full"] } and tracing, tracing-appender, tracing-subsriber (and am not sure if anything else) and it failed to build. Then I tried anyhow = "=1.0.59" and it passed.

Then I removed all the other dependencies (but I guess something could remain in my Cargo.lock changing the behaviour) and tried building the empty project with both anyhow = "=1.0.60" – it failed; and with anyhow = "=1.0.59" – this passed again.

Then I searched through the issues here and decided it must be something with the version. But maybe it was something one of the other dependencies did to my Cargo.lock? I have no idea what it could be though.

EDIT:
and just in case:

% rustc --version -v
rustc 1.62.1 (e092d0b6b 2022-07-16)
binary: rustc
commit-hash: e092d0b6b43f2de967af0887873151bb1c0b18d3
commit-date: 2022-07-16
host: x86_64-unknown-linux-gnu
release: 1.62.1
LLVM version: 14.0.5

[RalfJung]

Hm yes that is odd. Lockfiles AFAIK don't affect feature resolution so I don't see how there could be anything left in your lockfile that would cause this problem.

If you can replicate this situation again:

added anyhow = "1.0" and some other dependencies, among them tokio = { version = "1.0", features = ["full"] } and tracing, tracing-appender, tracing-subsriber (and am not sure if anything else) and it failed to build.

That would probably be helpful.

[myOmikron]

I had the same issue, after deleting my target/ it compiled without throwing any errors.

[RalfJung]

So maybe it is some issue with build script output being cached?

[Banyc]

Same issue here. This happened once, but was not reproducible after I deleted the target/ folder.

[djc]

I also ran into this after upgrading to anyhow 1.0.60 today:

error[E0554]: `#![feature]` may not be used on the stable release channel
   --> /Users/djc/.cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.60/src/lib.rs:214:32
    |
214 | #![cfg_attr(backtrace, feature(backtrace))]
    |                                ^^^^^^^^^

According to cargo tree -i anyhow, the only dependencies in my dep graph were my own crate (which only specified the version) and prost-derive 0.11, which also only specifies the version.

The output from cargo check -v:

    Running `rustc --crate-name anyhow --edition=2018 /Users/djc/.cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.60/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=1 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=e0e05d09e32292b9 -C extra-filename=-e0e05d09e32292b9 --out-dir /Users/djc/src/bolt/rust/gcp/target/debug/deps -L dependency=/Users/djc/src/bolt/rust/gcp/target/debug/deps --cap-lints allow --cfg backtrace`
     Running `rustc --crate-name anyhow --edition=2018 /Users/djc/.cargo/registry/src/github.com-1ecc6299db9ec823/anyhow-1.0.60/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=1 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=67e3df9d0ec0a44b -C extra-filename=-67e3df9d0ec0a44b --out-dir /Users/djc/src/bolt/rust/gcp/target/debug/deps -L dependency=/Users/djc/src/bolt/rust/gcp/target/debug/deps --cap-lints allow --cfg backtrace`

Which does have --cfg backtrace -- but I'm not sure why/where that is coming from? (My $RUSTFLAGS is empty, as are $RUSTC and $RUSTC_WRAPPER.) For me, too, the issue went away after jettisoning the target dir.

[lnicola]

For anyone running into this with rust-analyzer, a workaround is to run cargo check before loading the project in RA.

I think the problem is that we set RUSTC_WRAPPER to something that doesn't actually build anything in order to run the build scripts slightly faster. This makes the anyhow build script think the backtrace feature is available, and enable it even if not requested by the user.

This approach was inspired by IntelliJ Rust, which I suspect is also affected.

We have an option to disable this hack, but I don't think it's working at the moment. And since anyhow is pretty popular, it might turn out to be quite annoying.

[RalfJung]

I think the problem is that we set RUSTC_WRAPPER to something that doesn't actually build anything in order to run the build scripts slightly faster. This makes the anyhow build script think the backtrace feature is available, and enable it even if not requested by the user.

oh, yes that would explain it. If you always return exit code 0 then that would fool all the auto-detect in all the crates. Is there a rust-analyzer issue tracking this?

Also has 1.0.60 been un-yanked? I didn't even know that is possible...

[lnicola]

Is there a rust-analyzer issue tracking this?

No, just an option you can use to disable it. From RA's point of view, this is a feature because it speeds up project loading. I don't think we've ever spotted another crate doing feature detection like this.

[RalfJung]

It's IMO clearly a bug if you claim to a build script probe that compilation succeded. This is certainly not the only crate doing that; others include eyre, and there even is autocfg (14 million "recent" downloads on crates.io) to make it easy for crates to have such "probes" for particular features.

[RalfJung]

Reported as rust-lang/rust-analyzer#12973. I think this can be closed on the anyhow side.

[dtolnay]

Closing in favor of rust-lang/rust-analyzer#12973, since this is quite clearly a rust-analyzer bug based on the discussion above.

[RalfJung]

Btw, turns out the reason that only anyhow is affected (and only starting in 1.0.60) is that it respects RUSTC_WRAPPER, which eyre and autocfg don't do.

[silmeth]

For the time being, IMO some note in the README and/or the docs about the issue could be helpful – so that people encountering it can easily find out they should run cargo check before loading rust-analyzer, and when they’ve already hit this problem, remove the target dir.

[RalfJung]

As a work-around we could also remove the use of RUSTC_WRAPPER. Since that works fine for autocfg and eyre, it is unlikely to lead to problems.

[quertc]

Agree with the comment above, not sure if this is a good solution, but as a temporary option, this worked for me:

rm -rf target
cargo check

[sethwheway]

Please forgive me if I'm mistaken, but was this issue meant to be bypassed by the above PRs? I just ran into it on anyhow 1.0.66. It started happening after I created some cargo workspaces. Deleting target/ still fixes the issue thankfully.

Edit: I just saw rust-lang/rust-analyzer#12973 and it seems this issue should be fixed on the rust-analyzer end anyway? It happened on 1.64.0 so unless the fix didn't make it into that stable version I'm quite confused. I'll see if I can repro the issue again and may take it up with them

[dtolnay]

It was fixed a long time ago. At this point we are just keeping the "I use 4-month-old rust-analyzer (or intellij) because I enjoy hitting bugs that were already fixed in those projects 3 months ago" crowd entertained, so I'll lock this issue from further discussion at this point.