Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intermittent "feature cannot be used on stable release channel" #526

Open
jyn514 opened this issue Jan 25, 2023 · 19 comments
Open

Intermittent "feature cannot be used on stable release channel" #526

jyn514 opened this issue Jan 25, 2023 · 19 comments

Comments

@jyn514
Copy link

jyn514 commented Jan 25, 2023

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
Copy link
Author

jyn514 commented Jan 25, 2023

cc rust-lang/cargo#10367

@intgr
Copy link

intgr commented Jan 30, 2023

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

@p-kraszewski
Copy link

p-kraszewski commented Feb 24, 2023

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 added a commit that referenced this issue Feb 24, 2023
Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.
@sunfishcode
Copy link
Member

I submitted #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
Copy link
Author

jyn514 commented Feb 24, 2023

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 added a commit that referenced this issue Feb 28, 2023
* Add more `cargo:rerun-if-env-changed`'s to build.rs

Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.

* Don't include all the cargo features.
@sunfishcode
Copy link
Member

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

sunfishcode added a commit that referenced this issue Mar 4, 2023
* Add more `cargo:rerun-if-env-changed`'s to build.rs

Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.

* Don't include all the cargo features.
sunfishcode added a commit that referenced this issue Mar 4, 2023
* Add more `cargo:rerun-if-env-changed`'s to build.rs

Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.

* Don't include all the cargo features.
@sunfishcode
Copy link
Member

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

@p-kraszewski
Copy link

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

sunfishcode added a commit that referenced this issue Mar 29, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
sunfishcode added a commit that referenced this issue Mar 29, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
@mschneider
Copy link

just encountered it with rustix 0.37.7

@sunfishcode
Copy link
Member

@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
Copy link

mschneider commented Apr 8, 2023

The repo is: https://github.com/blockworks-foundation/mango-simulation
I ran cargo build lastly on blockworks-foundation/mango-simulation@5bea723 (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 added a commit that referenced this issue May 19, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
sunfishcode added a commit that referenced this issue May 19, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
@sunfishcode
Copy link
Member

sunfishcode commented Jun 17, 2023

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

@Luthaf
Copy link

Luthaf commented Jun 30, 2023

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
Copy link

Encountered this with rustix-0.38.4

@ynhame
Copy link

ynhame commented Oct 3, 2023

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
Copy link

ptdecker commented Oct 4, 2023

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
Copy link

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

sunfishcode added a commit that referenced this issue Oct 12, 2023
* Add more `cargo:rerun-if-env-changed`'s to build.rs

Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.

* Don't include all the cargo features.
sunfishcode added a commit that referenced this issue Oct 12, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
sunfishcode added a commit that referenced this issue Oct 12, 2023
* Add more `cargo:rerun-if-env-changed`'s to build.rs

Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.

* Don't include all the cargo features.
sunfishcode added a commit that referenced this issue Oct 12, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
sunfishcode added a commit that referenced this issue Oct 12, 2023
* Add more `cargo:rerun-if-env-changed`'s to build.rs

Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.

* Don't include all the cargo features.
sunfishcode added a commit that referenced this issue Oct 12, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
sunfishcode added a commit that referenced this issue Oct 12, 2023
* Add more `cargo:rerun-if-env-changed`'s to build.rs

Add more `cargo:rerun-if-env-changed`'s to build.rs for rustix's
features, configuration flags, and the toolchain variables rustix uses
for autoconfiguration, to hopefully ensure it gets rerun when anything
changes.

See also #526.

* Don't include all the cargo features.
sunfishcode added a commit that referenced this issue Oct 12, 2023
Now that we appear to have a known-working fix for #526, we can
investigate relaxing the fix. If #526 reappears, we now have a
known-working state we can quickly revert to.

Reports in #562 and #575 are that having rerun-if-env-changed=RUSTC
and rerun-if-env-changed=RUSTC_WRAPPER are triggering spurious rebuilds
in some situations, so remove these. In theory, cargo should already be
aware of these environment variables. In practice, there were reports of
build failures which had the appearance of using an older version of
rustc with build.rs output from a newer version of rustc, and it wasn't
clear what was happening. But, it's possible that #563 fixes the issue
properly. So let's try removing these rerun-if-env-changed lines, and
see if the problem resurfaces.

And, rerun-if-env-changed=TARGET is explicitly documented as being
unnecessary [here].

[here]: https://doc.rust-lang.org/cargo/reference/build-scripts.html
@theRookieCoder
Copy link

theRookieCoder commented Feb 20, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests