-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking issue for RFC 2523, #[cfg(version(..))]
#64796
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
Comments
@csmoe Are you working on this? If not I might want to try out this task first since @petrochenkov mentioned that this task is easier than |
@pickfire I didn't have much bandwidth on this, seems you have already made some progress on |
Can anyone please help to write up the mentoring instructions. Based on what I know, this should be similar to #64797 (comment)
I believed step 1 and 2 should be the same. For step 3, based on what I know requires me to modify somewhere around rust/src/libsyntax/attr/builtin.rs Lines 566 to 568 in b56b239
Based on |
Hi, @pickfire. Are you still working on this? |
No, I was stuck working on this and don't know how to proceed. |
Ok, thanks for quick response. I'll take my shot at this. |
@mibac138 Do you want me to publish my progress? |
@pickfire sure, that'd be great! |
@mibac138 Err, no need. You have already done more than me, I don't know how to change the |
Status update: #71314 implemented this RFC with a slightly different syntax - #[cfg(version("1.2.3"))] instead of The reason is that Additionally, the |
Implement RFC 2523, `#[cfg(version(..))]` Hi! This is my first contribution to rust, I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version("1.44.0"))]` (note the quotes). Tracking issue: rust-lang#64796
The RFC had an unresolved question about how this feature would interact with nightly/beta. Should Currently, the implementation returns true. E.G. for #![feature(cfg_version)]
fn main() {
test();
}
#[cfg(version("1.45.0"))]
fn test() {
println!("Yes")
}
#[cfg(not(version("1.45.0")))]
fn test() {
println!("No")
} IMO, this is a mistake. The main use-case for |
That sounds like good reasoning to me, but I've not been following this RFC that closely. @joshtriplett -- I feel like you were "liaison'ing" for this before we had a term for it, do you have a take? |
Nominating for lang-team meeting to discuss |
Which is most useful, the way it is, AFAICT. Isn't there a way to combine this with cfg test(s) for "train", e.g. beta or nightly and unstable feature gates? |
Code written for the stable compiler should not have to know about beta or nightly. |
I'm not surprised with that as a goal, but I can think of cases where for practical reasons I nead to dev on 1.45 nightly with expectation that it will then work on 1.45 stable. I'm surprised if I'm the only one. |
I've been the primary person who has expressed that we need I'm withdrawing that objection, and I think we should go ahead and ship I still believe it's incredibly important that we have And on the flip side, the sooner we do ship cc @epage @rust-lang/lang |
@rustbot labels -S-blocked +I-lang-radar Given the above, if you are someone who is able and interested in putting together a stabilization PR with a stabilization report for (Have a look at our new draft stabilization report template.) |
@joshtriplett I appreciate the insight from your change in perspective. In particular:
This comparison to browsers puts into perspective for me that Rust using version detection in lieu of feature detection is actually fine, since Rust features are tied to versions unlike browser features which vary wildly across vendors. Also, compile times have been a longstanding pain point of Rust adoption. So reducing the need for build scripts would be another big step along with the great effort that's been made in this area. |
With this unblocked, I realized it would be good to stabilize the rustc and cargo sides at the same time. I've created rust-lang/cargo#15531 to track the Cargo side of this. |
I think a stabilization on the rust side should be pretty straightforward. The one big remaining issue I see is testing. There is only one test right now added by #71314, and it only checks the parsing, not the actual functionality. I suppose we can extend I will file a PR in the coming days. Also needs a stabilization report, but that one should be easy. |
Stabilization PR filed: #141137 I'd like the lang team to decide on whether stabilization should sync up with cargo, or it is better to have support for There is also a limitation in the clippy lint |
I'm unclear on a point: What would be the effect of having it in rustc but not in cargo? Would it be usable on rustc somehow without the cargo support? |
@Lokathor the cargo side is tracked in rust-lang/cargo#15531. It's about supporting it in Cargo.toml, i.e.: [target.'cfg(not(version(1.70.0))`.dependencies]
is-terminal = "0.4.2" The rust side of course will work without cargo. |
Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change. PR rust-lang#81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`. This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR rust-lang#124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version. The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`. Pulled out of rust-lang#141137. Tracking issue: rust-lang#64796
Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change. PR rust-lang#81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`. This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR rust-lang#124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version. The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`. Pulled out of rust-lang#141137. Tracking issue: rust-lang#64796
Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change. PR rust-lang#81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`. This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR rust-lang#124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version. The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`. Pulled out of rust-lang#141137. Tracking issue: rust-lang#64796
Rollup merge of #141413 - est31:cfg_version_env_var, r=jieyouxu Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change. PR #81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`. This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR #124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version. The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`. Pulled out of #141137. Tracking issue: #64796
Pull out dedicated `cfg_version` syntax test from feature gate test Tracking issue: rust-lang#64796. Closes rust-lang#141452, as a follow-up to rust-lang#141413 (comment) (point 3 of that is probably too pedantic). The feature gate test was dual-purposing causing feature gate errors to distract from syntax exercises. `@rustbot` label +F-cfg_version r? `@est31`
Pull out dedicated `cfg_version` syntax test from feature gate test Tracking issue: rust-lang#64796. Closes rust-lang#141452, as a follow-up to rust-lang#141413 (comment) (point 3 of that is probably too pedantic). The feature gate test was dual-purposing causing feature gate errors to distract from syntax exercises. ``@rustbot`` label +F-cfg_version r? ``@est31``
Rollup merge of #141552 - jieyouxu:cfg-version-tests, r=est31 Pull out dedicated `cfg_version` syntax test from feature gate test Tracking issue: #64796. Closes #141452, as a follow-up to #141413 (comment) (point 3 of that is probably too pedantic). The feature gate test was dual-purposing causing feature gate errors to distract from syntax exercises. ``@rustbot`` label +F-cfg_version r? ``@est31``
Uh oh!
There was an error while loading. Please reload this page.
This is a tracking issue for
#[cfg(version(..))]
(rust-lang/rfcs#2523).Steps:
#[cfg(version(..))]
#71314#[cfg(version(...))]
#141137 (closed due to ahas_cfg_version
design consideration)#[cfg(version(...))]
, take 2 #141766Unresolved questions:
What is
cfg(version(...))
relative to in terms of nightly compilers?We could check against what
rustc --version
says, e.g. nightly being1.40.0
, beta being1.39.0
, and stable being1.38.0
. We could also havecfg(version(...))
at most be relative to the beta compiler. See the RFC for a longer discussion.#[cfg(version(..))]
#64796 (comment)Should we also support
version = "..."
so that crates having a MSRV below whenversion(...)
was stabilized can use the flag?Dependency updates cause language changes (src tarballs are vendored without respecting lockfile #79010)
The text was updated successfully, but these errors were encountered: