Version-typed cfgs

[tmandry]

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

[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]

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)

[traviscross]

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.

[tgross35]

(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 ❤️

[tgross35]

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?

[tgross35]

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.

[yoshuawuyts]

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.

[traviscross]

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.

[traviscross]

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")]

[tmandry]

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

[tmandry]

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.

[epage]

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]

This seems unrelated to the section it is under:

The version type integrates with existing compiler flags.

[epage]

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

[epage]

1. The "MSRV problem" is much smaller than this RFC makes it out to
2. 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]

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

[tmandry]

I model it as a sliding window where the crates want to support versions some number of years back. Eventually they bump their MSRV past the point where they have no feature gates that exist prior to this feature being stable. Example using made up versions...

1.25 - Current MSRV
1.30 - Feature A
1.35 - Feature B
1.40 - Feature C
1.45 - cfg_version
1.50 - Feature D
1.55 - Feature E

In this RFC you can bump MSRV to 1.40 and not need a build script anymore. Otherwise you have to wait to bump it to 1.45.

Of course it is a simplistic model. I don't think MSRVs of these crates are entirely time based but I think there are time-based constraints, imposed by e.g. Linux distros.

The year time frame is based on sampling; I recall looking at how far back the most recent feature gate was for each crate.