Skip to content

Tracking issue for RFC 3695: Allow boolean literals as cfg predicates #131204

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

Closed
3 of 4 tasks
clubby789 opened this issue Oct 3, 2024 · 13 comments · Fixed by #138632
Closed
3 of 4 tasks

Tracking issue for RFC 3695: Allow boolean literals as cfg predicates #131204

clubby789 opened this issue Oct 3, 2024 · 13 comments · Fixed by #138632
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-RFC-implemented Blocker: Approved by a merged RFC and implemented but not stabilized. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@clubby789
Copy link
Contributor

clubby789 commented Oct 3, 2024

This is a tracking issue for the RFC "Allow boolean literals as cfg predicates" (rust-lang/rfcs/#3695).
The feature gate for the issue is #![feature(cfg_boolean_literals)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

Unresolved Questions

None.

Related

@clubby789 clubby789 added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Oct 3, 2024
@traviscross traviscross changed the title Tracking Issue for RFC 3695: Allow boolean literals as cfg predicates Tracking issue for RFC 3695: Allow boolean literals as cfg predicates Oct 4, 2024
@traviscross traviscross added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Oct 4, 2024
@Urgau Urgau added the B-RFC-implemented Blocker: Approved by a merged RFC and implemented but not stabilized. label Jan 3, 2025
@Urgau
Copy link
Member

Urgau commented Jan 3, 2025

Call for testing

This is call for testing regarding RFC3695: Allow boolean literals as cfg predicates.

RFC 3695 adds support for true & false in #[cfg], #[cfg_attr] and cfg! predicates.

Testing instructions

Requires: nightly-2024-10-06 or newer with feature(cfg_boolean_literals).

  • Use #[cfg(true)], #[cfg(false)] with (or without) any/all/not.

Feedback

  • Did the feature work as expected?
  • Were there surprising results?

@rustbot label +call-for-testing

@rustbot rustbot added the call-for-testing Marks issues that require broader testing from the community, e.g. before stabilization. label Jan 3, 2025
@U007D
Copy link

U007D commented Jan 7, 2025

Hi. This will appear in This Week in Rust issue #581 under "Call for Testing". You may remove the call-for-testing label, or retain it (in which case it will appear again in the following issue of TWiR).

@clubby789
Copy link
Contributor Author

With a quick review:

  • #[cfg(true)], #[cfg(false)] and variants (all/any/not) work as expected
  • Same for cfg_attrs
  • cfg!(true) and cfg!(false) work
  • r#true and r#false are also unchanged as specified:
[poc.rs:4:5] cfg!(true) = true
[poc.rs:5:5] cfg!(false) = false
[poc.rs:6:5] cfg!(r#true) = false
[poc.rs:7:5] cfg!(r#false) = false

@U007D

This comment has been minimized.

@clubby789 clubby789 removed the call-for-testing Marks issues that require broader testing from the community, e.g. before stabilization. label Jan 14, 2025
@joshtriplett
Copy link
Member

Works well here, behaving exactly as expected.

@clubby789

This comment has been minimized.

@joshtriplett
Copy link
Member

Reference update at rust-lang/reference#1762 .

@joshtriplett

This comment has been minimized.

@rfcbot

This comment has been minimized.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Mar 17, 2025
@traviscross

This comment has been minimized.

@rfcbot

This comment has been minimized.

@rfcbot rfcbot removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Mar 17, 2025
@joshtriplett
Copy link
Member

@traviscross Good catch, yes, the FCP belongs on the PR.

@clubby789
Copy link
Contributor Author

#138632

@bors bors closed this as completed in 0de803c Apr 17, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-RFC-implemented Blocker: Approved by a merged RFC and implemented but not stabilized. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants