Skip to content

RFC: Allow boolean literals as cfg predicates #3695

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Oct 4, 2024

Conversation

clubby789
Copy link
Contributor

@clubby789 clubby789 commented Sep 16, 2024

This RFC proposes allowing boolean literals as cfg predicates, e.g. cfg(true) and cfg(false).


Rendered

Tracking:

@clarfonthey
Copy link

Also worth noting that, in addition to cfg(any()) meaning cfg(false), cfg(all()) means cfg(true) as well. So, both technically have easy versions, but I agree that true and false care clearer.

@joshtriplett joshtriplett added the T-lang Relevant to the language team, which will review and decide on the RFC. label Sep 16, 2024
@joshtriplett
Copy link
Member

This is simple, straightforward, solves an existing problem, and has no compatibility issues.

@rfcbot merge

@rfcbot
Copy link
Collaborator

rfcbot commented Sep 16, 2024

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Sep 16, 2024
@kennytm
Copy link
Member

kennytm commented Sep 16, 2024

the RFC should mention somewhere that the raw identifiers r#true and r#false continue to work:

rustc --cfg false --check-cfg 'cfg(r#false, values(none()))' 1.rs
#     ^~~~~~~~~~~
// 1.rs
#![deny(warnings)]

#[expect(unexpected_cfgs)]
mod a {
  #[cfg(r#true)]
  pub fn foo() {}
}

mod b {
  #[cfg(r#false)]
  pub fn bar() {}
}

fn main() { 
    b::bar()
}

@nikomatsakis
Copy link
Contributor

Yes please. I'm always surprised I can't do cfg(false).

@rfcbot reviewed

@clubby789
Copy link
Contributor Author

Added a note about r#true/r#false

@clubby789
Copy link
Contributor Author

Also worth noting that, in addition to cfg(any()) meaning cfg(false), cfg(all()) means cfg(true) as well.

Mentioned this in a couple of places for completeness

@lolbinarycat
Copy link
Contributor

probably should also mention cfg_attr for completeness

@traviscross
Copy link
Contributor

@rfcbot reviewed

In particular, now that we're warning about #[cfg(False)], #[cfg(FALSE)], etc., this is somewhat more pressing.

@rfcbot rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Sep 18, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Sep 18, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@workingjubilee
Copy link
Member

I agree we should just send bad news for anyone who was using cfg(false) and cfg(true) for any meaning beyond the obvious one.

@kennytm
Copy link
Member

kennytm commented Sep 18, 2024

current situation of cfg-like constructs

false r#false
Rust language
(#[cfg], cfg!, etc)
❌ `cfg` predicate key cannot be a literal
rustc --cfg
rustc --check-cfg ❌ invalid `--check-cfg` argument: `false` is a boolean literal
cargo [target.<cfg>] ❌ failed to parse `r#false` as a cfg expression: unexpected content `#false` found after cfg expression

I think cargo should be made to accept raw identifiers, but this is indeed really out-of-scope for this RFC.

@tmandry
Copy link
Member

tmandry commented Sep 18, 2024

Thanks for this RFC, I've wanted this for awhile!

@rfcbot reviewed

@T0mstone
Copy link

T0mstone commented Sep 20, 2024

Another future possibility that addresses the drawback: There could be an allow-by-default lint for using these, so you could #![deny(cfg_boolean_literal)] (or whatever it'd be called).

@lolbinarycat
Copy link
Contributor

note that lint names should be plural if they are nouns

@joshtriplett
Copy link
Member

We discussed this in today's @rust-lang/cargo meeting. We confirmed that we generally want Cargo to implement every cfg that rustc does, to avoid confusion, and that we anticipate this being easy to implement.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. to-announce and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Sep 28, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Sep 28, 2024

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@clubby789
Copy link
Contributor Author

Updated the name to cfg_boolean_literals: (rust-lang/rust#131034 (comment))

@traviscross traviscross merged commit 60a6758 into rust-lang:master Oct 4, 2024
@traviscross
Copy link
Contributor

The team has accepted this RFC, and it's now been merged.

Thanks to @clubby789 for writing this up and pushing it forward.

For further updates, follow the tracking issue:

bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 4, 2024
Implement RFC3695 Allow boolean literals as cfg predicates

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

r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Oct 4, 2024
Implement RFC3695 Allow boolean literals as cfg predicates

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

r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 4, 2024
Rollup merge of rust-lang#131034 - Urgau:cfg-true-false, r=nnethercote

Implement RFC3695 Allow boolean literals as cfg predicates

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

r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
@lolbinarycat
Copy link
Contributor

for posterity, here is the IRLO thread that lead to this RFC: https://internals.rust-lang.org/t/cfg-none-for-disabling-code/21520

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 17, 2025
…t, r=davidtwco,Urgau,traviscross

Stabilize `cfg_boolean_literals`

Closes rust-lang#131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in rust-lang#138293 so whichever doesn't land first will need updating

--

# Stabilization Report

## General design

### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?

[RFC 3695](rust-lang/rfcs#3695), none.

### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

None

### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?

None

## Has a call-for-testing period been conducted? If so, what feedback was received?

Yes; only positive feedback was received.

## Implementation quality

### Summarize the major parts of the implementation and provide links into the code (or to PRs)

Implemented in [rust-lang#131034](rust-lang#131034).

### Summarize existing test coverage of this feature

- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`

### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

The above mentioned issue; it should not block as it interacts with another unstable feature.

### What FIXMEs are still in the code for that feature and why is it ok to leave them there?

None

### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)

### Which tools need to be adjusted to support this feature. Has this work been done?

`rustdoc`'s  unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.

## Type system and execution rules

### What updates are needed to the reference/specification? (link to PRs when they exist)

A few lines to be added to the reference for configuration predicates, specified in the RFC.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 17, 2025
Rollup merge of rust-lang#138632 - clubby789:stabilize-cfg-boolean-lit, r=davidtwco,Urgau,traviscross

Stabilize `cfg_boolean_literals`

Closes rust-lang#131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in rust-lang#138293 so whichever doesn't land first will need updating

--

# Stabilization Report

## General design

### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?

[RFC 3695](rust-lang/rfcs#3695), none.

### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

None

### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?

None

## Has a call-for-testing period been conducted? If so, what feedback was received?

Yes; only positive feedback was received.

## Implementation quality

### Summarize the major parts of the implementation and provide links into the code (or to PRs)

Implemented in [rust-lang#131034](rust-lang#131034).

### Summarize existing test coverage of this feature

- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`

### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

The above mentioned issue; it should not block as it interacts with another unstable feature.

### What FIXMEs are still in the code for that feature and why is it ok to leave them there?

None

### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)

### Which tools need to be adjusted to support this feature. Has this work been done?

`rustdoc`'s  unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.

## Type system and execution rules

### What updates are needed to the reference/specification? (link to PRs when they exist)

A few lines to be added to the reference for configuration predicates, specified in the RFC.
github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Apr 19, 2025
…dtwco,Urgau,traviscross

Stabilize `cfg_boolean_literals`

Closes #131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating

--

# Stabilization Report

## General design

### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?

[RFC 3695](rust-lang/rfcs#3695), none.

### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

None

### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?

None

## Has a call-for-testing period been conducted? If so, what feedback was received?

Yes; only positive feedback was received.

## Implementation quality

### Summarize the major parts of the implementation and provide links into the code (or to PRs)

Implemented in [#131034](rust-lang/rust#131034).

### Summarize existing test coverage of this feature

- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`

### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

The above mentioned issue; it should not block as it interacts with another unstable feature.

### What FIXMEs are still in the code for that feature and why is it ok to leave them there?

None

### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)

### Which tools need to be adjusted to support this feature. Has this work been done?

`rustdoc`'s  unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.

## Type system and execution rules

### What updates are needed to the reference/specification? (link to PRs when they exist)

A few lines to be added to the reference for configuration predicates, specified in the RFC.
github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request Apr 22, 2025
### 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.3.0` has we are changing `CfgExpr`
enum in a semver incompatible change.

We currently have (thks to
#14671) a forward compatibility
warning against `cfg(true/false)` as identifiers instead of keywords.

~~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)`](https://github.com/search?q=lang%3Atoml+%2F%28%3F-i%29%5C%5Btarget%5C.%5B%27%22%5Dcfg.*true%2F&type=code)
and
[`cfg(false)`](https://github.com/search?q=lang%3Atoml+%2F%28%3F-i%29%5C%5Btarget%5C.%5B%27%22%5Dcfg.*false%2F&type=code),
I choose to gate the feature under a error and not a warning.~~
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Apr 28, 2025
…dtwco,Urgau,traviscross

Stabilize `cfg_boolean_literals`

Closes #131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating

--

# Stabilization Report

## General design

### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?

[RFC 3695](rust-lang/rfcs#3695), none.

### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

None

### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?

None

## Has a call-for-testing period been conducted? If so, what feedback was received?

Yes; only positive feedback was received.

## Implementation quality

### Summarize the major parts of the implementation and provide links into the code (or to PRs)

Implemented in [#131034](rust-lang/rust#131034).

### Summarize existing test coverage of this feature

- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`

### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

The above mentioned issue; it should not block as it interacts with another unstable feature.

### What FIXMEs are still in the code for that feature and why is it ok to leave them there?

None

### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)

### Which tools need to be adjusted to support this feature. Has this work been done?

`rustdoc`'s  unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.

## Type system and execution rules

### What updates are needed to the reference/specification? (link to PRs when they exist)

A few lines to be added to the reference for configuration predicates, specified in the RFC.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-lang Relevant to the language team, which will review and decide on the RFC. to-announce
Projects
None yet
Development

Successfully merging this pull request may close these issues.