cargo
cargo copied to clipboard
rust-lang
Implement RFC3695: Allow boolean literals as cfg predicates
What does this PR try to resolve?
This PR implements https://github.com/rust-lang/rfcs/pull/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
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
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
:umbrella: The latest upstream changes (presumably #14137) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (presumably #14752) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (presumably #14497) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (presumably ed31dad4307145f82a17eebe56a17a4d801a3382) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (presumably 10c255ad07766377c269058d40405bc17d79b50e) made this pull request unmergeable. Please resolve the merge conflicts.
The future incompatibility warning was merged in #14671.
I tried adding an unstable Cargo feature but that would I mean either making not insignificant refactor to the parsing or evaluation, or adding a hack to transform back, neither felt justified enough for such a temporary mechanism.
Therefore this PR is blocked on enough time having passed to being able to unconditional apply to new logic.
@rustbot label -S-waiting-on-review +S-blocked-external
:umbrella: The latest upstream changes (possibly 081d7bac633bbc72883fb74fb4993bb1b1a2df4a) made this pull request unmergeable. Please resolve the merge conflicts.
Therefore this PR is blocked on enough time having passed to being able to unconditional apply to new logic.
- Do we have any discussion of “enough time” elsewhere like on Zulip?
- Should we wait for stabilization of https://github.com/rust-lang/rust/issues/131204?
- Do we have any discussion of “enough time” elsewhere like on Zulip?
Not that I'm aware.
- Should we wait for stabilization of Tracking issue for RFC 3695: Allow boolean literals as cfg predicates rust#131204?
I'm planning on issuing after the holidays a call-for-testing and then directly propose a T-lang stabilization. This could mean only 1 or 2 releases with the future compact warning, not sure if you (T-cargo) would be comfortable with that.
We could also wait and stabilize both at the same time, but I don't think that's required.
:umbrella: The latest upstream changes (possibly 3a4abacae12aac2d826d169d4f77df723ae3b3b9) made this pull request unmergeable. Please resolve the merge conflicts.
:umbrella: The latest upstream changes (possibly 1566e4c346b1dd511492e760e9c02a12d6b1f61c) made this pull request unmergeable. Please resolve the merge conflicts.
We are currently having a T-lang FCP of the feature in https://github.com/rust-lang/rust/pull/138632 (with 5/5 check-boxes).
I'm expecting it to land in 1.88 (it branches at the end of this week), this should let a full release cycle for T-cargo to decide to land this at the same time. The future incompatibility warning landed in 1.85 so it would be 3 release cycles with the warning.
@rustbot labels -S-blocked-external -S-waiting-on-author -A-unstable +S-waiting-on-review
RFC3695 has now passed it's T-lang stabilization final comment period over at https://github.com/rust-lang/rust/pull/138632#issuecomment-2788152230
From my side yes, I don't know if you also want to do an FCP or if you consider the T-lang FCP to be enough, but either way the changes in this PR are at minimum ready for review.
Thanks for driving this!
We aren't holding our own FCP, relying on the T-compiler FCP
Once the test is cleaned up, this should be good to merge on our side.