Implement RFC3695: Allow boolean literals as cfg predicates #14649
Conversation
|
r? @weihanglo rustbot has assigned @weihanglo. Use |
rustbot
added
A-cfg-expr
src/cargo/util/context/target.rs
Outdated
| 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 { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I think an unstable-opt-in is fine to change from the future-incompat warning to the new behavior.
There was a problem hiding this comment.
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.
- The
target.'cfg(ture).rustflagsbeing a way to set/overwrite rustflagscargo --configshould be used instead, orRUSTFLAGSorCARGO_BUILD_RUSTFLAGS.
There was a problem hiding this comment.
Opened #14671 to address this thread (as this PR is already quite large).
|
☔ The latest upstream changes (presumably #14137) made this pull request unmergeable. Please resolve the merge conflicts. |
Urgau
force-pushed
the
cfg-true-false
branch
2 times, most recently
from
6bc170b
to
756003f
Compare
|
☔ The latest upstream changes (presumably #14752) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #14497) made this pull request unmergeable. Please resolve the merge conflicts. |
What does this PR try to resolve?
This PR implements rust-lang/rfcs#3695: allow boolean literals as cfg predicates, i.e.
cfg(true)andcfg(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>)']inCargo.toml/.cargo/config.toml.Additional information
I had to bump
cargo-platformto0.2.0has we are changingCfgExprenum in a semver incompatible change.I choose a use a
Cargo.tomlfeature (for the manifest) as well as a unstable CLI flag for the.cargo/config.tomlpart.Given the very small (two occurrences on Github Search) for
cfg(true)andcfg(false), I choose to gate the feature under a error and not a warning.