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.

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.

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

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

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.

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

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

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.

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

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.

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.

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

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

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.

Improved this section in 2323793.

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.

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

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.

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

This seems unrelated to the section it is under:

The version type integrates with existing compiler flags.

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

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

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".

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