At least with my initial search, I did not see any public uses

I assume you mean because of them using #[cfg(since(rust, "1.$BIG_NUMBER"))] or similar "point a loaded firearm directly at my lower limb" gestures? They sort of already can do that, with the classic example being mem::transmute of std entities with entirely-unspecified layouts, and then us changing it in a future version. But yes, strictly speaking it does introduce a new vector, and one we will inevitably hit in time rather than merely potentially.

I wonder if this is something that could be warn-by-default. Or at least warn-by-default in clippy. The warning would only be an issue when a workspace is worked on by rust versions older than their highest version cfg.

I don't think we have any way of detecting this. No toolchain can flag "too new" version requirements, because it's reasonable to detect things newer than that toolchain.

Also I would assume this problem already exists with rustversion.

Yes. I expect it will be very common to have a crate that is developed and tested primarily with an old rustc version and then have since used against a much later one so that new features can also be used selectively, so warning against this issue will mostly interfere with what may be the most popular pattern for using the feature.

It feels somewhat unclear to me why we would start this journey by supporting this new "version literal" type in cfg only and not in the language? As opposed to supporting integers first, which are supported in the language.

Note that I'm saying doing so is a potential alternative; I am not proposed we do. If we did so, the reason would be "because this RFC came first".

One depressingly verbose option, but one that will work without modification to the proposal, is to attach an additional "epoch version" via cfg, e.g.

#[cfg(
    all(
        since(thing, "1.0.0"), since(thing_epoch, "2")
    )
)]
mod something {}

#[cfg(
    all(
        since(thing, "1.1.0"), not(since(thing_epoch, "2"))
    )
)]
mod something {}

Obviously, since(thing, "1.0.0") would be satisfied by "1.1.0" in ordering without the all including an additional "version epoch".

Unsure how much we need to explore this as its a future possibility. The main question is whether we paint ourselves into a corner for target_version.

From @jmillikin at #3857 (comment)

How would this work with non-rustc compilers, such as gccrs? The current proposal treats the rustc release version as a Rust language version, which only really works in languages that have a single implementation (Python, Swift).

Looking forward into Rust's future slightly, imagine widespread adoption lead to something like today's C/C++ ecosystem. There are the three major toolchains (GCC, Clang, MSVC) plus various vendor compilers. Language version detection uses a vendor-neutral standard (__STDC_VERSION__, __cplusplus). Compiler-specific feature detection in libraries is uncommon and generally causes a lot of complaints (c.f. gnulib).

Rust doesn't currently have a versioned language specification, so the available non-vendor identifiers are the edition and the stability annotation feature names. A way to conditionally compile based on those identifiers might be something like this:

#[cfg(edition >= 2021)]
mod some_mod_for_2021_edition;

#[cfg(feature = "fs_try_exists")] // stabilized in rustc v1.81
use std::fs::exists as fs_exists;

#[cfg(not(feature = "fs_try_exists"))]
fn fs_exists(...) { /* open-coded impl of std::fs::exists for older toolchains */ }

Regarding conditional compilation based on edition, it's difficult to think of a concrete use case. The edition is part of the Cargo.toml library definition, so there's no case where the same source file will be compiled with different editions. In build systems that let the edition vary by detected toolchain (Bazel) the same mechanism can be used to select different source files and --cfg flags.

The stability annotation feature names haven't historically been exposed to stable Rust, so if they or something like them are to be used for compile-time toolchain feature detection then it might be worth considering whether a more structured format is appropriate.

From @matthieu-m at #3857 (comment)

@jmillikin I believe the preferred way to raise concerns is to raise targeted concerns as comments anchored on specified pieces of the RFC, in order to consolidate all related concerns in one place.

How would this work with non-rustc compilers, such as gccrs? The current proposal treats the rustc release version as a Rust language version, which only really works in languages that have a single implementation (Python, Swift).

First of all, 1.70 is a Rust language version. Thus if gccrs advertised 1.70 as the language version it would be expected to match the behavior of rustc 1.70.

Apart from that, I believe I already raised your concerns in my two reviews comments, on:

[Line 53] We are scoping this RFC down to "language version" but considering "vendor version" as it can be approximated by the "language version" and in case it breaks any ties in decisions.

I raised the concern about distinguishing language, compiler & standard library versions, and about introducing the concept of vendors for compiler & standard library.

[Line 512] ## Alternative designs

I raised the concern of available alternatives for a large variety of pieces: detecting language features, compiler features, and library features.

From @jmillikin at #3857 (comment)

@matthieu-m I expanded every review comment on this PR and didn't see any you posted. There's multiple RFCs related to conditional compilation depending on the compiler version, perhaps your comments were on a different one?

My concerns regarding conflating the version of Rust the language and rustc the compiler are not localized to any specific line in the file; if you'd prefer comments in the form of a per-line code review then I can do that, but the selection of the line would be ~arbitrary.

From @kornelski at #3857 (comment)

I don't think this comparison should support nightly versions. For purpose of this operator, a nightly Rust version should appear to have the last stable version preceding it (rustc "1.100-nightly" should act like "1.99").

This is because only the stable subset of features in nightlies can be expected to exist (hopefully) indefinitely in the future, and stable features can be checked using stable versions.

Not-yet-stable features don't have any guaranteed continuity, so a nightly feature available in "1.100-nightly" may not exist in "1.102-nightly", and may not even exist in "1.100" stable.

We have crates like ahash that are a ticking time bomb due to assuming that nightly features won't change in the future. Exposing nightly versions in this operator will encourage such assumptions.

For detecting what's in nightly Rust versions there could be a different operator, e.g. based on specific features and dates, checking "do you support turboencabulator feature the way it worked on 2026-01-01?".

From @0xllx0 at #3857 (comment)

I don't think this comparison should support nightly versions. For purpose of this operator, a nightly Rust version should appear to have the last stable version preceding it (rustc "1.100-nightly" should act like "1.99").
This is because only the stable subset of features in nightlies can be expected to exist (hopefully) indefinitely in the future, and stable features can be checked using stable versions.
Not-yet-stable features don't have any guaranteed continuity, so a nightly feature available in "1.100-nightly" may not exist in "1.102-nightly", and may not even exist in "1.100" stable.
We have crates like ahash that are a ticking time bomb due to assuming that nightly features won't change in the future. Exposing nightly versions in this operator will encourage such assumptions.
For detecting what's in nightly Rust versions there could be a different operator, e.g. based on specific features and dates, checking "do you support turboencabulator feature the way it worked on 2026-01-01?".

I don't know if I understand your argument here. Nightly features are inherently unstable, but a specific Nightly release will obviously have all the features of that release. It may also be known that feature x exists between 1.y-nightly and 1.z-nightly. Of course, users could match against the specific feature like you suggest, but that could get very verbose, very quickly. Checking against nightly version ranges allows one to target the common set of unstable features in those ranges.

Note that it is:

• nightly or not
• whether its included and the value is unstable

I was also annoyed with ahash and other packages that auto-enable nightly features and find the auto-enabling of nightly features to run counter to the spirit of nightly (unstable functionality is opt-in).

The focus here isn't on nightly detection but easing the way for adopting stabilized features. Yes, there is a risk that the feature may change. This is one of the reasons I added the pre-release marker compared to what T-lang had previously agreed to, to make it a more explicit opt-in. This will be up to T-lang who were previously convinced to not consider nightlies "complete" but were thoroughly convinced enough to go the other direction. If we find it becomes a problem, this can always be changed as the behavior is not specified.

In discussing this with T-lang today, there was interest in scoping this RFC down and that included punting on using pre-release for marking the language implementation is incomplete.

We ended up changing directions and going with a nightly is "incomplete".

I updated the RFC in 56ddfc3.

From @kornelski at #3857 (comment)

Currently #[cfg()] has its own microsyntax, being a language inside a language, with its own design that is quite different from Rust's expressions. There's a proposal to move away from that, and make it behave more like normal expressions, using &&/|| instead of all()/any(). Syntactically, this will end up allowing everything matching macro expr inside cfg().

I think it would be great to generally move towards using a syntax that's more natural as Rust expressions, and use >= and < for comparisons.

#[cfg(rust_version >= "1.99")]
#[cfg(rust_version < "1.99")]

There's a proposal for #[stable(since = "semver")] or #[doc(since = "semver")] attribute: rust-lang/rust#74182 and there's #[deprecated(since = "v")] already. Use of >= operator avoids giving since multiple roles.

From @tmandry at #3857 (comment)

What strikes me when considering @kornelski's comment above is that we haven't yet explored the idea of introducing a new type of cfg value for versions to the language.

This RFC introduces a new cfg predicate and a new check-cfg predicate to match. If we instead had typed cfg values we could redefine predicates like = to do something more specific for that type, in addition to defining additional predicates like >= and <.

The question is how to introduce values of a type. Following Rust, we can introduce them as version("1.85"). So on the command line you would say --cfg rust=version("1.85"), and in code you could write

#[cfg(rust >= version("1.85")]
#[cfg(rust < version("1.85")]

Again, following Rust, we could choose to allow comparison between a version on the left and a string literal on the right. Probably I would defer this for now, but could be convinced either way.

Beyond the syntactic improvements, this gives us some extra flexibility. For example:

• I can write --check-cfg cfg(rust >= version("1.85")) and this defines the set of operators that are allowed with that value.

• We can choose to enforce that all values of a cfg are the same type. Or in the case of versions, we can enforce that you only have one value to begin with.

• As a future possibility we could have something like cratename = version("1.100+metadata") check for an exact match to +metadata on the LHS, while a more general requirement like cratename = version("1.100") would ignore any metadata that happens to exist on the LHS. Supporting this kind of comparison in the current RFC is less straightforward.

I still support the current RFC; I think it's better than anything we've considered before and it gets the details right. But this other direction is worth considering as a possibility. Using typed comparisons instead of operators on strings feels more Rusty to me.

We've already reserved space for cfg types with rustc's --cfg foo="bar" syntax that requires the double quotes, so we might as well make use of it. And of course, another future possibility is to add integer configs.

Currently #[cfg()] has its own microsyntax, being a language inside a language, with its own design that is quite different from Rust's expressions. There's a proposal to move away from that, and make it behave more like normal expressions, using &&/|| instead of all()/any(). Syntactically, this will end up allowing everything matching macro expr inside cfg().

For the record, I'm very much open to this direction. I don't think it cuts strongly against a comparison operator like since(), since that already looks like a function call.

From @traviscross at #3857 (comment)

If we instead had typed cfg values we could...

What I'd really like eventually is to not have a DSL here at all and just use Rust within cfg attributes. We already have a Rust interpreter on hand -- consteval. Obviously nothing from the crate itself would be in scope.

Clearly I don't think cfg_version should wait for that. But when we start talking about typed cfg values, generic predicates, and, presumably therefore, type inference and type checking for cfg, it does make me wonder whether using Rust here and consteval might not be more straightforward after all.

I've covered binary operators and types in 674ec04. This greatly enlarges the scope of this RFC which has me worried about this being available in a reasonable time frame and, if we go down this route, I wonder if we should have a short-term solution, like rust_version("1.95").

From @traviscross

What I'd really like eventually is to not have a DSL here at all and just use Rust within cfg attributes. We already have a Rust interpreter on hand -- consteval. Obviously nothing from the crate itself would be in scope.

Keep in mind that Cargo also parses and evaluates the syntax.

We'd also have to figure out how concepts like name-only cfg's translates to "rust".

Can't we write this as --cfg foo=1?

We can also consider implicit types. I recorded this in be94add.

My suggestion is to use cfg(rust >= version("1.95")).

Recorded this in 79f50aa