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

Question

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

silmeth opened this issue 2 years ago · 25 comments

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)

Answer 1 · 2022-08-03T12:46:08.000Z

Confirming this issue.

Answer 2 · 2022-08-03T13:34:03.000Z

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" }

Answer 3 · 2022-08-03T13:58:55.000Z

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

Answer 4 · 2022-08-04T13:39:58.000Z

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.

Answer 5 · 2022-08-05T13:50:54.000Z

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?

Answer 6 · 2022-08-05T14:09:03.000Z

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

Answer 7 · 2022-08-05T14:20:37.000Z

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.

Answer 8 · 2022-08-06T15:26:46.000Z

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

Answer 9 · 2022-08-06T17:26:28.000Z

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

Answer 10 · 2022-08-08T03:42:18.000Z

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

Answer 11 · 2022-08-08T09:21:34.000Z

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.

Answer 12 · 2022-08-08T10:45:33.000Z

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.

Answer 13 · 2022-08-08T11:09:33.000Z

Would it make sense to remove the detection of the Error::backtrace method entirely? It has never been available on stable and since the latest couple of nightlies it doesn't exist on nightly anymore too.

Answer 14 · 2022-08-08T11:24:53.000Z

Ref rust-lang/rust#99431, rust-lang/rust#72981.

Answer 15 · 2022-08-08T13:02:51.000Z

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...

Answer 16 · 2022-08-08T13:07:10.000Z

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.

Answer 17 · 2022-08-08T13:08:15.000Z

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.

Answer 18 · 2022-08-08T13:11:22.000Z

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

Answer 19 · 2022-08-08T14:03:49.000Z

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

Answer 20 · 2022-08-08T14:18:12.000Z

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.

Answer 21 · 2022-08-08T14:43:37.000Z

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.

Answer 22 · 2022-08-08T14:54:32.000Z

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.

Answer 23 · 2022-08-09T16:52:41.000Z

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

Answer 24 · 2022-11-02T19:26:14.000Z

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

Answer 25 · 2022-11-02T20:34:51.000Z

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.