Version-typed cfgs #3905

tmandry · 2026-01-07T02:39:45Z

This RFC proposes a general mechanism for version-based conditional compilation called "typed cfgs".

Summary

This RFC proposes "typed cfgs", a new form of conditional compilation predicate that understands types. Initially, this RFC proposes to add support for version-typed cfgs, allowing for ergonomic version comparisons against the language version supported by the compiler. This would be exposed through two new built-in cfg names:

rust_version, which can be compared against a language version literal, e.g., #[cfg(rust_version >= "1.85")].
rust_edition, which can be compared against an edition literal, e.g., #[cfg(rust_edition >= "2024")].

This design solves a long-standing problem of conditionally compiling code for different Rust versions without requiring build scripts or forcing libraries to increase their Minimum Supported Rust Version (MSRV). It also replaces the cfg(version(..)) part of RFC 2523.

History

There have been several previous attempts to solve the problem of conditional compilation by Rust version.

RFC RFC: #[cfg(accessible(..) / version(..))] #2523 introduced #[cfg(version(..))]. However, it left the syntax as an open question. Attempts to stabilize it were blocked because the new syntax would be a hard error on older compilers, defeating the goal of supporting older MSRVs.
RFC RFC: #[cfg(version_since(rust, "1.95"))] for Rust-version conditional compilation #3857 proposed #[cfg(version_since(rust, ...))], which solved the MSRV problem and generalized the mechanism beyond Rust versions while defining the interaction with command line flags like --check-cfg.

This RFC takes the lessons from both previous attempts. It proposes a path to the ergonomic rust_version >= "..." syntax that was preferred during language team discussions, while providing a clear MSRV-compatibility story from day one.

The RFC also incorporates use cases from the cfg_target_version RFC (#3750), which proposed a way to compare against the version of the target platform's SDK (e.g., #[cfg(target_version(macos >= "10.15"))]). Version-typed cfgs provide a path to supporting these comparions.

Finally, it takes cues from previous discussions around mutually exclusive features and a cfg_value!() macro, and lays out a path toward more single-valued config types that could support these features.

Rendered

text/0000-typed-cfgs.md

@programmerjake

Thanks to @programmerjake for the Chromium example.

weiznich

Overall I linke the idea, but I have some questions and remarks

(Obvious disclaimer: I'm not associated with any team, that's just my personal opinion, so feel free to ignore that)

weiznich · 2026-01-07T10:58:21Z

text/0000-version-typed-cfgs.md

+#[cfg(rust_edition >= "2021")]
+fn my_function() {
+    // use a feature only available from the 2021 edition onwards
+}
+```
+
+Note that because new compilers can still compile older editions, the `#[cfg(rust_edition)]` stacking pattern is less useful than it is for `rust_version`. The primary use case for rust_edition is within macros or code generation that needs to produce different code depending on the edition context it's being expanded into.


I would be interested in seeing an actual example where this would have been useful. As far as I know macros use the same edition of the crate defining the macro, not the edition of the calling crate.

(Well beside emitting errors that a crate/generated code doesn't support edition 2024 or something like that, which might be problematic for the ecosystem overall)

Code generation is the motivating case. In shipping the 2024 edition, we tracked various problems related to this such as:

Generate unsafe extern blocks (Edition 2024) rust-bindgen#2901

(While we shipped unsafe extern in all editions, the generator could maintain a lower MSRV on its output if that output included #[cfg(rust_edition))] in some cases. The generator could support, of course, an --edition flag to conditionalize its output rather than conditionalizing in the output, but that asks more of users, and in general it's convenient when the same generated code can be accepted across editions.)

We also tracked certain macro-related problems such as:

Fix Rust edition 2024 compatibility wasm-bindgen/wasm-bindgen#4259

[edition 2024] missing_unsafe_on_extern in macros with older editions rust#132425

rust_2024_incompatible_pat bad suggestion with proc-macro when brace comes from input rust#132963

Bad suggestion for macro_rules macros generated from a proc-macro rust#132906

Use edition of macro_rules when compiling the macro rust#133274

regression: a value of type HashMap<Pulse, u64> cannot be built from rust#135669

Nested macro_rules and edition spans rust#137031

matches! problem with edition 2021 rust#84429

document and test the precise span that triggers edition-dependent behavior rust#86539

With macros that define macros, edition hygiene does not actually work in the way that we might ideally like. Maybe or maybe not #[cfg(rust_edition))] could have helped in averting some problems. Even if not, it doesn't bother me; it's the code generation case I find motivating.

text/0000-typed-cfgs.md

text/0000-version-typed-cfgs.md

text/0000-typed-cfgs.md

text/0000-version-typed-cfgs.md

tgross35 · 2026-01-07T20:59:00Z

(Obvious disclaimer: I'm not associated with any team, that's just my personal opinion, so feel free to ignore that)

RFCs are the place for community feedback. Insight from future feature users that aren't team members is just as (if not more) valuable, and always welcome in all discussion areas ❤️

text/0000-typed-cfgs.md

text/0000-version-typed-cfgs.md

tgross35 · 2026-01-08T03:18:45Z

text/0000-typed-cfgs.md

@@ -0,0 +1,265 @@
+- Feature Name: typed_cfgs


Sort of a meta comment: this RFC is called typed_cfgs Unless I overlooked something, however, it only talks about version-typed configs, and that is of course the main content of the RFC. Maybe "Version-typed cfgs" would be a more fitting name?

Title aside, if accepting this RFC means accepting the concept of "typed cfgs", I think something about the mental model here is worth introducing in its own section. E.g. is existing config syntax "untyped"? Or is this proposing that cfg(all(foo, bar = "baz", version >= "1.2.3")) can be thought of as something like:

struct Version(/* ... */); impl PartialOrd<&str> for Version { /* ... */ } fn cfg_predicate(foo: bool, bar: Set, version: Version, ...) -> bool { [foo, bar.contains("baz"), version >= "1.2.3"].iter().all() }

For some prior art, C says that everything in an #if declaration gets intmax_t type and the expression must evaluate to an integer, which is then compared to 0.

Hah, I was just typing up a question about this myself, only to realize this is asking basically the same thing. The Effectful Target Tracking experiment wants to bring cfg-predicates into the type system as effect types. If we can spell out how typed cfgs could (at least conceptually) be lowered to types, that would be what we need to figure out how to bridge the two.

I believe @traviscross asked something similar in a previous lang team meeting, about potentially making cfg-features resolvable by const-eval/comptime functions. I believe to explore that too, having a (conceptual) type system representation would be helpful as well.

TC said:

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.

Or is this proposing that cfg(all(foo, bar = "baz", version >= "1.2.3")) can be thought of as something like:

struct Version(/* ... */); impl PartialOrd<&str> for Version { /* ... */ } fn cfg_predicate(foo: bool, bar: Set, version: Version, ...) -> bool { [foo, bar.contains("baz"), version >= "1.2.3"].iter().all() }

I'd rather prefer, e.g., if we could write something like:

#[cfg_eval(OPTS.contains("foo") && OPTS.get_eq("bar", "baz") && version >= "1.2.3")]

You're right about the title. I renamed the RFC in b5e9e5c.

My mental model is that existing cfgs are a set of strings-or-none, like you suggest with the code sample. I'm not sure where this would go in the RFC.

text/0000-version-typed-cfgs.md

epage · 2026-01-09T18:31:09Z

text/0000-version-typed-cfgs.md

+# Future possibilities
+[future-possibilities]: #future-possibilities


Having clippy take cfg rust_version comparisons into account? See https://github.com/rust-lang/rfcs/blob/4551bbd827eb84fc6673ac0204506321274ea839/text/3857-cfg-version.md#clippy

epage · 2026-01-09T18:32:15Z

text/0000-version-typed-cfgs.md

+- Increased compiler complexity. This introduces a new concept of "typed" `cfg`s into the compiler, which adds complexity to the parsing and evaluation logic for conditional compilation.
+- Subtlety of MSRV-preserving patterns: The need for the "stacked `cfg`" pattern (`#[cfg(rust_version)] #[cfg(rust_version >= ...)]` and `#[cfg_attr(rust_version, cfg(rust_version >= ...))]`) is subtle. While we will add lints to guide users, it's less direct than a simple predicate. However, this subtlety is the explicit tradeoff made to achieve MSRV compatibility.
+- The "stacked `cfg`" pattern does not work inside Cargo, so users will not be able to use this feature in Cargo until their MSRV is bumped. For cases where a dependency needs to be conditional on the Rust version, one can define a "polyfill" crate and make use of the MSRV-aware feature resolver, like the `is_terminal_polyfill` crate does.
+- Conditional compilation adds testing complexity. In practice, most crate maintainers only test their MSRV and the latest stable.


The impact can be reduced by tools like cargo hack that let you test across ranges for rust versions

epage · 2026-01-09T18:32:40Z

text/0000-version-typed-cfgs.md

+
+This approach delivers the most critical functionality to users quickly, while allowing more time to finalize the design for user-defined version predicates.
+
+# Drawbacks


From #3857

Libraries could having ticking time bombs that accidentally break or have undesired behavior for some future Rust version that can't be found until we hit that version.

epage · 2026-01-09T18:33:43Z

text/0000-version-typed-cfgs.md

+
+This approach delivers the most critical functionality to users quickly, while allowing more time to finalize the design for user-defined version predicates.
+
+# Drawbacks


Handling pre-releases in the future with a general syntax is fraught with issues, see https://github.com/rust-lang/rfcs/blob/4551bbd827eb84fc6673ac0204506321274ea839/text/3857-cfg-version.md#pre-releases-for-major-versions

epage · 2026-01-09T18:41:57Z

text/0000-version-typed-cfgs.md

+- How should pre-release identifiers in version strings be handled? This RFC proposes not supporting pre-release identifiers in version strings passed on the command line for now. For comparisons, this RFC proposes that if a pre-release identifier is present in a `cfg` predicate (e.g., `rust_version < "2.0-alpha"`), the pre-release part is ignored for the comparison (so it's treated as `2.0`), and a lint is emitted. This ensures forward compatibility, as comparisons like `cfg(all(foo >= "2.0-alpha", foo < "2.0"))` become trivially false on older compilers, which is a safe outcome. This behavior can be refined before stabilization.
+- Should the builtin `rust_version` and `rust_edition` be printed with `--print cfg` on the command line? We'd like the eventual answer to be "yes", but existing tools that parse the output might break with the new `rust_version=version("1.99")` syntax. If we can manage the breakage we should; otherwise we can gate it on a future edition.
+
+# Future possibilities


Clippy lint for using this with cfg_alias so people centralize knowledge of the version and have named identifiers to work from. See also https://github.com/rust-lang/rfcs/blob/4551bbd827eb84fc6673ac0204506321274ea839/text/3857-cfg-version.md#clippy-lint-prefer-using-cfgversion_since-via-cfg_alias

traviscross · 2026-01-10T01:00:02Z

text/0000-version-typed-cfgs.md

+There is a single, unified parsing and comparison logic that is part of the language's semantics. Additional checks for the built-in version keys are implemented as lints.
+
+*   The comparison is performed component-by-component, filling in any missing components with `0`. For example, a predicate `my_cfg >= "1.5"` will evaluate to true for versions `1.5.0`, `1.6.0`, and `2.0`, but false for `1.4.9`.
+*   For `rust_version`, a lint will be issued if the literal has more than two components (e.g., `"1.92.0"`). This is because language features should not depend on patch releases.


This is because language features should not depend on patch releases.

They shouldn't, but they do sometimes. We've reverted things in patch releases, causing behaviors to flip. It seems reasonable to me that a (particularly careful) library author might reasonably use this mechanism to handle such errors on our part.

traviscross · 2026-01-10T01:10:17Z

text/0000-version-typed-cfgs.md

+*   The comparison is performed component-by-component, filling in any missing components with `0`. For example, a predicate `my_cfg >= "1.5"` will evaluate to true for versions `1.5.0`, `1.6.0`, and `2.0`, but false for `1.4.9`.
+*   For `rust_version`, a lint will be issued if the literal has more than two components (e.g., `"1.92.0"`). This is because language features should not depend on patch releases.
+    *   A new lint, `useless_version_constraint`, warns for version checks that are logically guaranteed to be true or false (e.g., `rust_version >= "1.20"` when the feature was stabilized in 1.90).
+*   For `rust_edition`, a lint will be issued if the literal has more than one component or if we know the value is never going to be a Rust edition (for example, `"2019"`).


For rust_edition, a lint will be issued if the literal has more than one component...

Speaking with an edition hat on, we do not guarantee that we might not in the future ship an edition with a dot, e.g. "2028.06". If we were to lint this, it would mean that someone on an older toolchain compiling valid code produced by a generator handling this new edition would get the warning. Maybe that's OK. Maybe generators would suppress this diagnostic anyway. It's something to think about.

My understanding was edition names were kept open ended originally but we have little reason to do anything else at this point. This came up because there was a proposal to change package.edition to an integer.

cc @joshtriplett

tmandry

I haven't gotten through all the latest comments but will continue going through them tomorrow.

tmandry · 2026-01-13T03:16:07Z

text/0000-version-typed-cfgs.md

+The primary blockers for existing solutions have been:
+
+- **Build Scripts are a Poor Solution:** The only stable tool for this today is a build script (`build.rs`). However, build scripts add significant compilation overhead and are clunky to write and maintain.
+- **Previous Attempts had Flaws:** Past RFCs have tried to solve this, but ran into an unfortunate issue: their proposed syntax, e.g. `#[cfg(version(1.85))]`, was a syntax error on older compilers. This means that to use the feature, a library would first have to bump its MSRV to the version that introduced the syntax, somewhat defeating the primary purpose of the feature.


My intent is not to connotate something irredeemable. I don't think "flaws" does that, but I am open to suggestions on wording.

I agree we are in the realm of engineering tradeoffs, but I would add some additional context, e.g. the lack of an established decision or consensus on the existing syntax/naming and the chance to solve new problems we discovered in the meantime.

text/0000-version-typed-cfgs.md

tmandry · 2026-01-13T03:20:21Z

text/0000-version-typed-cfgs.md

+*   For `rust_version`, a lint will be issued if the literal has more than two components (e.g., `"1.92.0"`). This is because language features should not depend on patch releases.
+    *   A new lint, `useless_version_constraint`, warns for version checks that are logically guaranteed to be true or false (e.g., `rust_version >= "1.20"` when the feature was stabilized in 1.90).
+*   For `rust_edition`, a lint will be issued if the literal has more than one component or if we know the value is never going to be a Rust edition (for example, `"2019"`).


I'm leaving that feature of --check-cfg as a future possibility, which I describe below. I agree it would be nice and might consider including it in the RFC. On the other hand we can add it later, and we might benefit from seeing how it gets used in the ecosystem.

text/0000-version-typed-cfgs.md

tmandry · 2026-01-13T03:30:31Z

text/0000-version-typed-cfgs.md

+*   For `rust_version`, a lint will be issued if the literal has more than two components (e.g., `"1.92.0"`). This is because language features should not depend on patch releases.
+    *   A new lint, `useless_version_constraint`, warns for version checks that are logically guaranteed to be true or false (e.g., `rust_version >= "1.20"` when the feature was stabilized in 1.90).
+*   For `rust_edition`, a lint will be issued if the literal has more than one component or if we know the value is never going to be a Rust edition (for example, `"2019"`).
+*   Pre-release identifiers (e.g., `"1.92-beta"`) are not supported in this RFC. They will be ignored during comparison and a lint will be emitted. See the "Unresolved Questions" section for further discussion.


We should specify the set of accepted prereleases upfront. I'll add that to the RFC.

tmandry · 2026-01-13T03:43:53Z

text/0000-version-typed-cfgs.md

+The primary blockers for existing solutions have been:
+
+- **Build Scripts are a Poor Solution:** The only stable tool for this today is a build script (`build.rs`). However, build scripts add significant compilation overhead and are clunky to write and maintain.
+- **Previous Attempts had Flaws:** Past RFCs have tried to solve this, but ran into an unfortunate issue: their proposed syntax, e.g. `#[cfg(version(1.85))]`, was a syntax error on older compilers. This means that to use the feature, a library would first have to bump its MSRV to the version that introduced the syntax, somewhat defeating the primary purpose of the feature.


Also, this bullet is really about RFC 2523 specifically. I'll add wording to clarify that.

tmandry · 2026-01-13T03:50:21Z

text/0000-version-typed-cfgs.md

+    --check-cfg 'cfg(my_app_version, version())'
+    ```
+
+    This will accept any version value, but lint when the option is used as something other than a version. This is a more sensible default for versions, which don't have the equivalent of `values(none())`.


It was unclear; improved the wording in 2da8ddb.

On the default, the only other possibility I see is to lint on every version comparison with that option. I'm having a hard time seeing how that's useful or desirable.

text/0000-version-typed-cfgs.md

tmandry · 2026-01-13T03:53:47Z

text/0000-version-typed-cfgs.md

+The primary blockers for existing solutions have been:
+
+- **Build Scripts are a Poor Solution:** The only stable tool for this today is a build script (`build.rs`). However, build scripts add significant compilation overhead and are clunky to write and maintain.
+- **Previous Attempts had Flaws:** Past RFCs have tried to solve this, but ran into an unfortunate issue: their proposed syntax, e.g. `#[cfg(version(1.85))]`, was a syntax error on older compilers. This means that to use the feature, a library would first have to bump its MSRV to the version that introduced the syntax, somewhat defeating the primary purpose of the feature.


Improved this section in 2323793.

epage · 2026-01-13T16:52:27Z

text/0000-version-typed-cfgs.md

+```text
+version_literal :
+    NUMERIC_COMPONENT ('.' NUMERIC_COMPONENT)*
+
+NUMERIC_COMPONENT :
+    '0'
+  | ('1'...'9') ('0'...'9')*


I find the use of the word "component" to be confusing, for instance I had missed that the future possibility about components was even referring to this.

semver.org refers to them as version identifiers. I tend to refer to them as "fields" within the version.

epage · 2026-01-13T16:54:33Z

text/0000-version-typed-cfgs.md

+- **More expressive check-cfg:** We can support specifying an expected number of components in check-cfg, or an expected set of values to compare against, as in editions:
+    - `--check-cfg 'cfg(foo, version("2018", "2022", "2025"))'`
+    - `--check-cfg 'cfg(foo, version(values >= "1.75"))'`
+    - `--check-cfg 'cfg(foo, version(components <= 2))'`


Combining the description with the example makes it easier to see what the intent is

Suggested change

- **More expressive check-cfg:** We can support specifying an expected number of components in check-cfg, or an expected set of values to compare against, as in editions:

- `--check-cfg 'cfg(foo, version("2018", "2022", "2025"))'`

- `--check-cfg 'cfg(foo, version(values >= "1.75"))'`

- `--check-cfg 'cfg(foo, version(components <= 2))'`

- **More expressive check-cfg:**, including

- supported versions (discrete) `--check-cfg 'cfg(foo, version("2018", "2022", "2025"))'`

- supported versions (range) `--check-cfg 'cfg(foo, version(values >= "1.75"))'`

- max supported precision within a version`--check-cfg 'cfg(foo, version(components <= 2))'`

epage · 2026-01-13T17:02:02Z

text/0000-version-typed-cfgs.md

+*   For `rust_version`, a lint will be issued if the literal has more than two components (e.g., `"1.92.0"`). This is because language features should not depend on patch releases.
+    *   A new lint, `useless_version_constraint`, warns for version checks that are logically guaranteed to be true or false (e.g., `rust_version >= "1.20"` when the feature was stabilized in 1.90).
+*   For `rust_edition`, a lint will be issued if the literal has more than one component or if we know the value is never going to be a Rust edition (for example, `"2019"`).
+*   Pre-release identifiers (e.g., `"1.92-beta"`) are ignored during comparison and a lint will be emitted. The comparison acts as if the pre-release was not specified. See the "Unresolved Questions" section for further discussion.


Another breaking change from this:

< "1.75.0" with 1.75.0-dev.1:

With this RFC, evaluates to true because the pre-release is ignored

When pre-releases are supported, would evaluate to false because all pre-releases are less than non-pre-releases.

epage · 2026-01-13T17:07:47Z

text/0000-version-typed-cfgs.md

+
+*   The comparison is performed component-by-component, filling in any missing components with `0`. For example, a predicate `my_cfg >= "1.5"` will evaluate to true for versions `1.5.0`, `1.6.0`, and `2.0`, but false for `1.4.9`.
+*   For `rust_version`, a lint will be issued if the literal has more than two components (e.g., `"1.92.0"`). This is because language features should not depend on patch releases.
+    *   A new lint, `useless_version_constraint`, warns for version checks that are logically guaranteed to be true or false (e.g., `rust_version >= "1.20"` when the feature was stabilized in 1.90).


Why is this indented? This is not further information about a number of components lint but describing a completely different lint, making it harder to notice (case in point: #3905 (comment))

epage · 2026-01-13T17:10:41Z

text/0000-version-typed-cfgs.md

+
+*   **`--print check-cfg`**: The built-in `rust_version` and `rust_edition` cfgs are implicitly included, so `rustc --print=check-cfg` will always list them. We can add these immediately because `--print check-cfg` is unstable.
+
+*   **Clippy**: Clippy's `incompatible_msrv` lint should be updated to respect `rust_version` checks, avoiding false positives when code is guarded by a sufficient `rust_version`.


This seems unrelated to the section it is under:

The version type integrates with existing compiler flags.

epage · 2026-01-13T17:12:14Z

text/0000-version-typed-cfgs.md

+    This will accept any version value, but lint when the option is used in a non-version comparison (note that this is an error if the option actually has a version-typed value). This is a more sensible default for versions, which don't have the equivalent of `values(none())`.
+
+*   **`--print cfg`**: User-defined version cfgs are printed in the `name=version("...")` format. Whether to print the built-in `rust_version` and `rust_edition` cfgs is left as an unresolved question to be determined based on tool compatibility. In future editions, the builtin cfgs should always be printed.
+    *   Note: Using editions being careful about passing `--edition` to `rustc --print cfg` invocations, which `cargo` for example does not currently do. This could introduce unexpected inconsistencies.


I feel like this could easily be lost when discussing the unresolved question around this. Should this be moved under the unresolved question?

epage · 2026-01-13T17:12:50Z

text/0000-version-typed-cfgs.md

+- How should pre-release identifiers in version strings be handled? This RFC proposes not supporting pre-release identifiers in version strings passed on the command line for now. For comparisons, this RFC proposes that if a pre-release identifier is present in a `cfg` predicate (e.g., `rust_version < "2.0-alpha"`), the pre-release part is ignored for the comparison (so it's treated as `2.0`), and a lint is emitted. This ensures forward compatibility, as comparisons like `cfg(all(foo >= "2.0-alpha", foo < "2.0"))` become trivially false on older compilers, which is a safe outcome. This behavior can be refined before stabilization.
+- Should the builtin `rust_version` and `rust_edition` be printed with `--print cfg` on the command line? We'd like the eventual answer to be "yes", but existing tools that parse the output might break with the new `rust_version=version("1.99")` syntax. If we can manage the breakage we should; otherwise we can gate it on a future edition.


Are these intentionally be left to be resolved during stabilization or are these meant to be resolved before the RFC is approved?

…nethercote Make `--print=check-cfg` output compatible `--check-cfg` arguments This PR changes significantly the output of the unstable `--print=check-cfg` option. Specifically it removes the ad-hoc resemblance with `--print=cfg` in order to output a simplified but still compatible `--check-cfg` arguments. The goal is to future proof the output of `--print=check-cfg` like `--check-cfg` is, and the best way to do that is to use it's syntax. This is particularly relevant for [RFC3905](rust-lang/rfcs#3905) which wants to introduce a new predicate: `version(...)`.

Rollup merge of #150840 - print-check-cfg-rework-output, r=nnethercote Make `--print=check-cfg` output compatible `--check-cfg` arguments This PR changes significantly the output of the unstable `--print=check-cfg` option. Specifically it removes the ad-hoc resemblance with `--print=cfg` in order to output a simplified but still compatible `--check-cfg` arguments. The goal is to future proof the output of `--print=check-cfg` like `--check-cfg` is, and the best way to do that is to use it's syntax. This is particularly relevant for [RFC3905](rust-lang/rfcs#3905) which wants to introduce a new predicate: `version(...)`.

epage · 2026-01-14T20:28:59Z

text/0000-version-typed-cfgs.md

+### Why this design?
+The syntax `rust_version >= "1.85"` is highly intuitive and directly expresses the user's intent. It is a general design that can be used to solve an entire class of adjacent problems, including platform versioning. It is a principled design, as by introducing a `version` type to the `cfg` system, we create a sound basis for comparison operators and other config types in the future. The syntax avoids the semantic confusion of proposals like `rust_version = "1.85"` which would have overloaded the meaning of `=` for a single special case.
+
+This design directly solves the MSRV problem in a way that RFC 2523 did not. The fact that crates maintaining an MSRV will be able to adopt it for newer version constraints buys back some of the time that was spent designing and implementing the newer iteration of this feature.[^buy-back] While sometimes it is better to ship something functional quickly, the fact that users have an functional workaround in the form of build scripts pushes the balance more in the direction of waiting to deliver a high quality solution.


The "MSRV problem" is much smaller than this RFC makes it out to

This feels contrary to the understanding I walked away from RustWeek and the initial revived discussions from RFC 2523. Even the conversations we've had in private last month about this. At those it made it sound like "we need this sooner than later to resolve the build script performance issue" while this is saying "we can take our time".

epage · 2026-01-14T20:31:40Z

text/0000-version-typed-cfgs.md

+Single-valued config types give us a chance to revisit some earlier decisions like the use of `=` in predicates. For now these are a hard error. Future extensions might add `==` comparisons with a more natural meaning for single-valued configs.
+
+[^buy-back]:
+    A quick [sample][crate-sample] of two MSRV-preserving popular crates that already make use of feature gating, serde and proc-macro2, showed that those crates would be able to drop their build scripts roughly **a year earlier** with a solution that did not break MSRV compatibility. Obviously, this analysis is incomplete, but it has the benefit of emphasizing popular crates that show up in the critical path of many build graphs.


I am not seeing the logical connection between that link, the data, and this statement.

Add typed cfgs RFC

0ac8748

clarfonthey reviewed Jan 7, 2026

View reviewed changes

text/0000-typed-cfgs.md Outdated Show resolved Hide resolved

ehuss added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jan 7, 2026

programmerjake reviewed Jan 7, 2026

View reviewed changes

text/0000-typed-cfgs.md Outdated Show resolved Hide resolved

theemathas reviewed Jan 7, 2026

View reviewed changes

text/0000-typed-cfgs.md Outdated Show resolved Hide resolved

theemathas reviewed Jan 7, 2026

View reviewed changes

text/0000-typed-cfgs.md Outdated Show resolved Hide resolved

theemathas reviewed Jan 7, 2026

View reviewed changes

text/0000-typed-cfgs.md Outdated Show resolved Hide resolved

tmandry added 4 commits January 6, 2026 21:25

Improve guide-level section and motivation

9e41ebf

Clarify that = with version is a hard error

7c6744d

Don't lint on potential future editions

a26e0ec

Generalize to any number of version components

14e2c4e

Thanks to @programmerjake for the Chromium example.

weiznich reviewed Jan 7, 2026

View reviewed changes

clarfonthey reviewed Jan 7, 2026

View reviewed changes

text/0000-version-typed-cfgs.md Show resolved Hide resolved

programmerjake reviewed Jan 7, 2026

View reviewed changes

text/0000-version-typed-cfgs.md Show resolved Hide resolved

tgross35 reviewed Jan 7, 2026

View reviewed changes

text/0000-typed-cfgs.md Outdated Show resolved Hide resolved

text/0000-version-typed-cfgs.md Show resolved Hide resolved

Urgau reviewed Jan 7, 2026

View reviewed changes

text/0000-typed-cfgs.md Outdated Show resolved Hide resolved

tgross35 reviewed Jan 7, 2026

View reviewed changes

text/0000-version-typed-cfgs.md Show resolved Hide resolved

tmandry added 7 commits January 7, 2026 15:41

Clean up wording in reference-level and alternatives sections

0b9c25f

Reference-level: Version-typed cfgs as options

49b34d8

Clarify what happens when the same cfg is specified multiple times

99ad7cb

Elaborate the diagnostic use case

4131682

Fix parsing ambiguity in check-cfg

3545fd1

Elaborate check-cfg possibilities

ccb85c5

Clarify check-cfg version() behavior

00ec293

tgross35 reviewed Jan 8, 2026

View reviewed changes

hanna-kruppe reviewed Jan 8, 2026

View reviewed changes

text/0000-version-typed-cfgs.md Show resolved Hide resolved

Urgau mentioned this pull request Jan 8, 2026

Make --print=check-cfg output compatible --check-cfg arguments rust-lang/rust#150840

Merged

tmandry added 2 commits January 8, 2026 16:39

Rename feature to version_cfgs

cb977fb

Drawbacks wording

359d341

epage reviewed Jan 9, 2026

View reviewed changes

traviscross reviewed Jan 10, 2026

View reviewed changes

tmandry added 3 commits January 12, 2026 19:27

Add context on RFC 2523 to motivation

2323793

Clarify language around pre-releases

12a2df7

Respond to feedback on compiler flag section

2da8ddb

tmandry commented Jan 13, 2026

View reviewed changes

epage reviewed Jan 13, 2026

View reviewed changes

tmandry added 3 commits January 13, 2026 14:21

Break out reference-level section for builtin cfgs

ba3add3

Add reference-level section on lint names

243cfa7

Explicitly don't specify language pre-release behavior

eb9a0ae

tmandry added 4 commits January 13, 2026 14:47

Split apart compiler flag section

008fc9d

Improve version predicate definition

db89480

Add perfect-enemy-good drawback

b356fa0

Rework rationale and alternatives

cde6a91

epage reviewed Jan 14, 2026

View reviewed changes

		# Future possibilities
		[future-possibilities]: #future-possibilities


		This approach delivers the most critical functionality to users quickly, while allowing more time to finalize the design for user-defined version predicates.

		# Drawbacks


		* `--print check-cfg`: The built-in `rust_version` and `rust_edition` cfgs are implicitly included, so `rustc --print=check-cfg` will always list them. We can add these immediately because `--print check-cfg` is unstable.

		* Clippy: Clippy's `incompatible_msrv` lint should be updated to respect `rust_version` checks, avoiding false positives when code is guarded by a sufficient `rust_version`.

		- How should pre-release identifiers in version strings be handled? This RFC proposes not supporting pre-release identifiers in version strings passed on the command line for now. For comparisons, this RFC proposes that if a pre-release identifier is present in a `cfg` predicate (e.g., `rust_version < "2.0-alpha"`), the pre-release part is ignored for the comparison (so it's treated as `2.0`), and a lint is emitted. This ensures forward compatibility, as comparisons like `cfg(all(foo >= "2.0-alpha", foo < "2.0"))` become trivially false on older compilers, which is a safe outcome. This behavior can be refined before stabilization.
		- Should the builtin `rust_version` and `rust_edition` be printed with `--print cfg` on the command line? We'd like the eventual answer to be "yes", but existing tools that parse the output might break with the new `rust_version=version("1.99")` syntax. If we can manage the breakage we should; otherwise we can gate it on a future edition.

Version-typed cfgs #3905

Are you sure you want to change the base?

Version-typed cfgs #3905

Conversation

tmandry commented Jan 7, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

History

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

weiznich left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tgross35 commented Jan 7, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yoshuawuyts Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Jan 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Jan 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmandry left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tmandry commented Jan 7, 2026 •

edited by rustbot

Loading

yoshuawuyts Jan 8, 2026 •

edited

Loading

traviscross Jan 9, 2026 •

edited

Loading

traviscross Jan 10, 2026 •

edited

Loading

traviscross Jan 10, 2026 •

edited

Loading

tmandry left a comment •

edited

Loading

tmandry Jan 13, 2026 •

edited

Loading