Intermittent "feature cannot be used on stable release channel"

[jyn514]

I temporarily got this error trying to build rustix as a dependency:

error[E0554]: `#![feature]` may not be used on the stable release channel
--> /Users/jyn/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustix-0.36.4/src/lib.rs:99:26
   |
99 | #![cfg_attr(rustc_attrs, feature(rustc_attrs))]
   |                          ^^^^^^^^^^^^^^^^^^^^

I have unfortunately not been able to reproduce this error; I updated the version of rustix, which I originally thought fixed the issue, but when I downgraded to 0.36.4 I couldn't reproduce it again.

I think the build script needs to have rerun-if-env-changed=RUSTC or something like that? If it helps, my default toolchain is nightly but I have a rust-toolchain file that says to use 1.65.

[jyn514]

cc https://github.com/rust-lang/cargo/issues/10367

[intgr]

FWIW running rm -rf target to delete the cache fixed this issue for me.

[p-kraszewski]

I have this very error popping in my various projects (95% of the time related to rustix). A simple cargo clean is a fix, but it forces me to fully recompile big projects, which is slightly annoying.

Sometimes just adding a new dependency to my projects triggers it.

[sunfishcode]

I submitted https://github.com/bytecodealliance/rustix/pull/544 in hopes that it may help. However, I don't yet have a reliable way to reproduce the problem locally, so I can't say for sure whether it does.

[jyn514]

I have this very error popping in my various projects (95% of the time related to rustix). A simple cargo clean is a fix, but it forces me to fully recompile big projects, which is slightly annoying.

@p-kraszewski as a workaround, you can use cargo clean -p rustix to only recompile rustix instead of all your dependencies

[sunfishcode]

#544, which may fix this, is now released in version 0.37.

[sunfishcode]

Does anyone who encountered this issue continue to see it with 0.37, or 0.36.11?

[p-kraszewski]

Not encountered within at least the last 2 weeks. Thank you.

[mschneider]

just encountered it with rustix 0.37.7

[sunfishcode]

@mschneider Could you say which codebase you encountered in it, whether you use an IDE or a tool like cargo-watch, and anything special about your build configuration that might be applicable?

[mschneider]

The repo is: https://github.com/blockworks-foundation/mango-simulation I ran cargo build lastly on https://github.com/blockworks-foundation/mango-simulation/commit/5bea7236cb63f034c7f7c8877c13c1b4e5d27fc4 (you might not be able to repro this one, because someone force pushed a git branch linked as dependency so cargo won't be able to resolve to the cargo locked commit) then ran cargo update -p mango-feeds-connector to fix the above issue, and then ran cargo build, which presented me with the above error message

Then rm -rfed the target directory and ran build again and everything is working now.

I do use visual studio code with rust-analyzer, which is usually very aggressive in running cargo check

[sunfishcode]

@mschneider Have you seen any instances of this problem since your initial report here?

[Luthaf]

I just saw an instance of the same issue with rustix v0.37.20. rm -rf target fixed it, but I'm not sure how to reproduce. Might have been related to me starting a build simultaneously from the command line and from inside vscode with rust-analyzer.

[JohnDowson]

Encountered this with rustix-0.38.4

[ynhame]

This did also happen to me on 0.37.24. The only thing I did was a cargo update followed by a cargo clippy. As mentioned above doing cargo clean -p rustix solved the issue.

[ptdecker]

Encountered this with rustix-0.38.4.

Here is a partial cargo tree of my project indicating which of my dependencies are using this package:

[corporate project]
├── reqwest v0.11.20
│   ├── hyper-tls v0.5.0
│   │   ├── native-tls v0.2.11
│   │   │   └── tempfile v3.7.0
│   │   │       └── rustix v0.38.4
└── [corporate private module]
    ├── criterion v0.5.1
    │   ├── is-terminal v0.4.9
    │   │   └── rustix v0.38.4 (*)

[benjaminleonard]

Ran into this issue with rustix 0.37.23 – after a fresh install. Fixed by running: cargo clean -p rustix

[theRookieCoder]

Encountered this with rustix 0.37.27, cargo clean and deleting the target directory does not fix it for me. This only happens on rust analyzer for some reason (yes I did restart the server and vs code too), compiling from the command line works perfectly fine.

[spitfire05]

This seems unrelated to rust-analyzer itself, the thing is, using stable rust a project referencing rustix will fail with this error on cargo check (or cargo clippy), but build fine w/o errors on cargo build. Strange.