-
Notifications
You must be signed in to change notification settings - Fork 161
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
Comments
FWIW running |
I have this very error popping in my various projects (95% of the time related to Sometimes just adding a new dependency to my projects triggers it. |
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.
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. |
@p-kraszewski as a workaround, you can use |
* 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.
#544, which may fix this, is now released in version 0.37. |
* 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.
* 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.
Does anyone who encountered this issue continue to see it with 0.37, or 0.36.11? |
Not encountered within at least the last 2 weeks. Thank you. |
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
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
just encountered it with rustix 0.37.7 |
@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? |
The repo is: https://github.com/blockworks-foundation/mango-simulation 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 |
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
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 Have you seen any instances of this problem since your initial report here? |
I just saw an instance of the same issue with rustix v0.37.20. |
Encountered this with |
This did also happen to me on |
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:
|
Ran into this issue with |
* 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.
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
* 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.
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
* 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.
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
* 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.
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
Encountered this with |
This seems unrelated to rust-analyzer itself, the thing is, using stable rust a project referencing rustix will fail with this error on |
I temporarily got this error trying to build rustix as a dependency:
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 isnightly
but I have arust-toolchain
file that says to use 1.65.The text was updated successfully, but these errors were encountered: