-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
cargo::
syntax should be permitted despite MSRV with the right configuration
#13868
Comments
Strictly Cargo-related. @rustbot transfer cargo |
Does the single colon version work for you? ( |
Huh yeah that works, thanks! Maybe the lint could suggest the single-colon version instead? Or maybe the MSRV error could note the single-colon version as an alternative in its help text? |
They are all good suggestions! @Urgau any opinion on this? Should we mention only single-colon syntax everywhere to avoid compatibility hazard? |
I don't know if we should mention it in the diagnostic output it's already quite heavy; also mentioning the single column wouldn't be useful for the majority of users. However I think like in the blog post we could mention it in the documention of |
Maybe it could be mentioned in the MSRV error, since that's a case where you know for a fact that it's relevant to the user? Ie, an error that says something like "note that you can get this to work by using |
I am open to this. We could emit such a suggestion if the given instruction is one of the prefix in this list: cargo/src/cargo/core/compiler/custom_build.rs Lines 703 to 721 in 85a4d70
|
I'll look into this. |
Just want to point out that the docs are misleading, as they say
implying that this switchover happened with 1.77 when support for the But the good news is that (at least with 1.80 nightly), |
That is an oddity from the order of things being implemented compared to the order they were stabilized. |
I assumed as much (it’s why I thought to try it to begin with), but I’m grateful for the workaround all the same! |
We just ran into this same problem in PyO3. Will there ever be a point where the deprecated We typically have quite low MSRV (currently 1.63) and are worried that we might reach a state where we cannot use |
No it hasn't been and will not be removed. check-cfg is in a weird state because of the stabilization order, though it should be generally fine with a single colon. Anything didn't work as expected? |
All working ok, for now we're just sticking with |
Currently, zerocopy's
build.rs
script contains the following:We have a lot of
cfg
s that are now triggering the recently-addedunexpected_cfgs
lint. In order to fix this, I added the following to our build script:Note that this is gated to only run on Rust version 1.77 or later, since that's when the
cargo::
syntax was introduced.Unfortunately, this causes the following error to be emitted:
This is spurious since our version detection logic will ensure that we don't emit these annotations prior to 1.77, but since it's a hard error, there's no way to work around it.
It would be great if there were a way to ask Cargo to disable this error for cases like these. The alternative for us is to just add a blanket
#![allow(unexpected_cfgs)]
, which would be a shame since that lint is genuinely useful.(I will also note that this error seems especially odd given that pre-1.77 toolchains simply ignore
cargo::
; it doesn't cause a compilation error or even a warning)The text was updated successfully, but these errors were encountered: