Implement RFC3695: Allow boolean literals as cfg predicates #14649

Urgau · 2024-10-06T14:50:01Z

What does this PR try to resolve?

This PR implements rust-lang/rfcs#3695: allow boolean literals as cfg predicates, i.e. cfg(true) and cfg(false).

How should we test and review this PR?

The PR should be reviewed commit by commit and tested by looking at the tests and using [target.'cfg(<true/false>)'] in Cargo.toml/.cargo/config.toml.

Additional information

I had to bump cargo-platform to 0.2.0 has we are changing CfgExpr enum in a semver incompatible change.

I choose a use a Cargo.toml feature (for the manifest) as well as a unstable CLI flag for the .cargo/config.toml part.

Given the very small (two occurrences on Github Search) for cfg(true) and cfg(false), I choose to gate the feature under a error and not a warning.

Create and link the tracking issue for the Cargo side

rustbot · 2024-10-06T14:50:07Z

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

src/cargo/util/context/target.rs

epage · 2024-10-07T15:42:51Z

src/cargo/util/context/target.rs

+        if let Ok(Platform::Cfg(cfg_expr)) = key.parse() {
+            cfg_expr.walk_expr(|e| match e {
+                CfgExpr::True | CfgExpr::False => {
+                    if !gctx.cli_unstable().cfg_boolean_literals {


Should we have a deprecation/future-incompat warning for Name("true") / Name("false") in existing versions, here and in toml?

If we do this, then no point in moving the if like I mentioned

Strictly speaking, so long as a user doesn't set --cfg false, the use of #[cfg(false)] won't fundamentally change, so maybe we don't need a future-incompat for that?

Should we have a deprecation/future-incompat warning for Name("true") / Name("false") in existing versions, here and in toml?

We could, but I don't think it's worth it, we only have two users and I expect the RFC to become stable relatively quickly.

Strictly speaking, so long as a user doesn't set --cfg false, the use of #[cfg(false)] won't fundamentally change

Technically that's not true for rustc as #[cfg(false)] was never legal before the RFC.

Two users on github. That isn't a complete search of all code. I'm just hesitant about turning this into a hard error without any prior notice.

@weihanglo, thoughts?

Technically that's not true for rustc as #[cfg(false)] was never legal before the RFC.

If we treat it as a Cargo bug, we can literally ship this breaking change 😬.

Being conservative, I vote for warnings. We could give a “clear timeline” when it will become a hard error, and note that in our CHANGELOG.

I wonder what other cfg value rustc disallows but Cargo is happy with. We may also fix them altogether.

Technically the syntax is called MetaItem and what is allowed inside the #[cfg(...)] attribute is defined by the MetaItemInner syntax, which accepts a MetaItem (paths, idents, ...) or an Expression, which can be a lot of things, the most interesting one is the literals one which has true | false 😄.

All of the other literals seems to be correctly rejected by Cargo.

I didn't test the other kinds of expressions but I suspect they will all be rejected as the Cargo parser doesn't like anything that isn't a ident or string.

However all of the keywords (async, return, while, ...) are NOT rejected by Cargo.
They are just regular idents for Cargo, like are true&false today.

If we treat it as a Cargo bug, we can literally ship this breaking change 😬.

That's my position, I would consider the Cargo parser to be in-sufficient and buggy, and just ship the breaking change ...

Being conservative, I vote for warnings. We could give a “clear timeline” when it will become a hard error, and note that in our CHANGELOG.

... but that doesn't seems to be either of your position. 😄

Which leads me to ask, what kind of warning you want? A future-incompatibility warning with no change in behaviour? A warning but with change in behaviour? Or a future-incompatibility warning but with unstable flag and feature to change the behaviour?

That last one would be my preferred one, as it would allow nightly testing, but it would be the most involved as currently the parsing is done via <CfgExpr as FromStr>::from_str(&str) which doesn't take any options, which will would need to configure the parser behaviour.

I think an unstable-opt-in is fine to change from the future-incompat warning to the new behavior.

We may also want to update the doc to note that some cfg values are not intended to use. Even if they are valid in Cargo.toml or .cargo/config.toml, they are unlikely to be picked by rustc.

There are two categories I can think of people might misuse:

[target.'cfg(true)'.dependencies] being a way to activate additional features

The [features] table is the right approach of it.

target.'cfg(ture).rustflags being a way to set/overwrite rustflags

cargo --config should be used instead, or RUSTFLAGS or CARGO_BUILD_RUSTFLAGS.

Opened #14671 to address this thread (as this PR is already quite large).

src/cargo/util/context/target.rs

epage · 2024-10-08T16:51:29Z

A more generalized search: https://github.com/search?q=%2F%28%3F-i%29cfg%5C%28.*%5Cb%28true%7Cfalse%29%5Cb%2F+language%3ATOML&type=code&ref=advsearch

bors · 2024-10-08T21:50:26Z

☔ The latest upstream changes (presumably #14137) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2024-10-31T21:56:13Z

☔ The latest upstream changes (presumably #14752) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2024-11-06T17:48:25Z

☔ The latest upstream changes (presumably #14497) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2024-11-15T20:28:30Z

☔ The latest upstream changes (presumably ed31dad) made this pull request unmergeable. Please resolve the merge conflicts.

@epage

…ts (#14671) ### What does this PR try to resolve? This PR tries to address this thread #14649 (comment) in #14649 regarding `cfg(true)`/`cfg(false)` (and keywords more generally) which are wrongly accepted[^1] as ident. To address this, this PR does two things: 1. it introduce a future-incompatibility warning against those (wrongly) accepted keywords as ident 2. it add parsing for raw-idents (`r#true`) add suggest-it in the warning ### How should we test and review this PR? This PR should be reviewed commit-by-commit. Tests are included in preliminary commits. ### Additional information I added a new struct for representing `Ident`s which is rawness aware. Which implied updating `cargo-platform` to `0.2.0` due to the API changes. r? @epage [^1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ccfb9c894dbf14e791c8ae7e4798efd0

bors · 2024-11-26T20:28:44Z

☔ The latest upstream changes (presumably 10c255a) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot assigned weihanglo Oct 6, 2024

rustbot added A-cfg-expr Area: Platform cfg expressions A-documenting-cargo-itself Area: Cargo's documentation A-manifest Area: Cargo.toml issues A-unstable Area: nightly unstable support S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 6, 2024

Urgau force-pushed the cfg-true-false branch from 9ec1325 to 83702cb Compare October 6, 2024 15:05

epage reviewed Oct 7, 2024

View reviewed changes

src/cargo/util/context/target.rs Outdated Show resolved Hide resolved

epage reviewed Oct 7, 2024

View reviewed changes

src/cargo/util/context/target.rs Outdated Show resolved Hide resolved

epage reviewed Oct 7, 2024

View reviewed changes

src/cargo/util/context/target.rs Outdated Show resolved Hide resolved

Urgau force-pushed the cfg-true-false branch from 83702cb to e554049 Compare October 8, 2024 08:23

Urgau force-pushed the cfg-true-false branch 2 times, most recently from 6bc170b to 756003f Compare October 9, 2024 08:07

Urgau mentioned this pull request Oct 11, 2024

Add future-incompat warning against keywords in cfgs and add raw-idents #14671

Merged

Urgau force-pushed the cfg-true-false branch from 756003f to 41dd924 Compare November 2, 2024 12:38

Urgau force-pushed the cfg-true-false branch from 41dd924 to a7294ad Compare November 9, 2024 12:22

Urgau added 4 commits November 15, 2024 22:08

Bump cargo-platform to 0.2.0 in preparation for cfg(<true/false>)

1c2bd8c

Add CfgExpr::walk_expr utility method

5d32d0d

Add tests in preparation of boolean literal support in cfgs

f846781

Add support for boolean literals in target cfgs

e358842

Urgau force-pushed the cfg-true-false branch from a7294ad to e358842 Compare November 15, 2024 21:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement RFC3695: Allow boolean literals as cfg predicates #14649

Implement RFC3695: Allow boolean literals as cfg predicates #14649

Urgau commented Oct 6, 2024 •

edited

Loading

rustbot commented Oct 6, 2024

epage Oct 7, 2024 •

edited

Loading

epage Oct 7, 2024

Urgau Oct 8, 2024

epage Oct 8, 2024

weihanglo Oct 9, 2024

Urgau Oct 10, 2024

Urgau Oct 10, 2024

epage Oct 10, 2024

weihanglo Oct 10, 2024

Urgau Oct 11, 2024

epage commented Oct 8, 2024

bors commented Oct 8, 2024

bors commented Oct 31, 2024

bors commented Nov 6, 2024

bors commented Nov 15, 2024

bors commented Nov 26, 2024

Implement RFC3695: Allow boolean literals as cfg predicates #14649

Are you sure you want to change the base?

Implement RFC3695: Allow boolean literals as cfg predicates #14649

Conversation

Urgau commented Oct 6, 2024 • edited Loading

What does this PR try to resolve?

How should we test and review this PR?

Additional information

rustbot commented Oct 6, 2024

epage Oct 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

epage commented Oct 8, 2024

bors commented Oct 8, 2024

bors commented Oct 31, 2024

bors commented Nov 6, 2024

bors commented Nov 15, 2024

bors commented Nov 26, 2024

Urgau commented Oct 6, 2024 •

edited

Loading

epage Oct 7, 2024 •

edited

Loading