Skip to content

Allow &&, ||, and ! in cfg #3796

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.

Sign up for GitHub

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Allow &&, ||, and ! in cfg #3796

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
edf0059
Start cfg-logical-ops
jhpratt Mar 30, 2025
b32e356
Fix mistake in and/or syntax
jhpratt Mar 31, 2025
7c87c36
update from feedback
jhpratt Mar 31, 2025
9dd2445
clarify `=` precedence
jhpratt Mar 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
146 changes: 146 additions & 0 deletions text/0000-cfg-logical-ops.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,146 @@
- Feature Name: `cfg_logical_ops`
- Start Date: 2025-03-30
- RFC PR: [rust-lang/rfcs#3796](https://github.com/rust-lang/rfcs/pull/3796)
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)

# Summary
[summary]: #summary

`#[cfg]`, `#[cfg_attr]`, and `cfg!()` can use `&&`, `||`, and `!` for `all`, `any`, and `not`,
respectively.

# Motivation
[motivation]: #motivation

While there are no technical restrictions to using logical operators, this was not always the case.
In Rust 1.0, attributes could not contain arbitrary tokens. This restriction was lifted in Rust
1.34, but the `cfg` syntax was not updated to take advantage of this. By letting developers use
logical operators, we are _lessening_ the burden of having to remember the `cfg` syntax.

# Explanation
[explanation]: #explanation
[cfg-syntax]: https://doc.rust-lang.org/reference/conditional-compilation.html#r-cfg.syntax
[precedence]: https://doc.rust-lang.org/reference/expressions.html#expression-precedence

`#[cfg(foo && bar)]` enables the annotated code if and only if both `foo` **and** `bar` are enabled.
Similarly, `#[cfg(foo || bar)]` enables the annotated code if and only if either `foo` **or** `bar`
is enabled. Finally, `#[cfg(!foo)]` enables the annotated code if and only if `foo` is **not**
enabled. `#[cfg_attr]` and `cfg!()` behave the same way.

Precedence is the [same as in expressions][precedence], with `=` being treated as `==` for this
purpose.

## Examples

| Syntax | Equivalent to | Rationale |
| ---------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `a && b` | `all(a, b)` | definition of `&&` |
| `a \|\| b` | `any(a, b)` | definition of `\|\|` |
| `!a` | `not(a)` | definition of `!` |
| `(a)` | `a` | definition of `()` |
| `a && b && c && d` | `all(a, b, c, d)` (or `all(all(all(a, b), c), d)`) | `&&` is associative |
| `a \|\| b \|\| c \|\| d` | `any(a, b, c, d)` (or `any(any(any(a, b), c), d)`) | `\|\|` is associative |
| `!!!!!!a` | `not(not(not(not(not(not(a))))))` | `!` can be repeated |
| `((((((a))))))` | a | `()` can be nested |
| `a && b \|\| c && d` | `any(all(a, b), all(c, d))` | `\|\|` has lower precedence than `&&` |
| `a \|\| b && c \|\| d` | `any(a, all(b, c), d)` | `\|\|` has lower precedence than `&&` |
| `(a \|\| b) && (c \|\| d)` | `all(any(a, b), any(c, d))` | `()` can be used for grouping |
| `!a \|\| !b && !c` | `any(not(a), all(not(b), not(c)))` | `!` has highest precedence |
| `feature="foo" \|\| feature="bar"` | `any(feature="foo", feature="bar")` | `\|\|` has lower precedence than `=` |
| `feature="foo" && feature="bar"` | `all(feature="foo", feature="bar")` | `&&` has lower precedence than `=` |
| `!feature="foo"` | _syntax error_ | `!` has higher precedence than `=`, which may be confusing, so we ban this syntax |
| `!(feature="foo")` | `not(feature="foo")` | use `()` for grouping |
Comment on lines +49 to +52
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(starting an inline discussion for brainstorming key = "val" syntax stemming from #3796 (comment))

FWIW I find S(e) to be a quite natural way to represent e ∈ S, but that is probably because of my background in type theory where sets are often modeled as predicates ("functions with return type bool", basically), and so asking "is this value in the set" is literally a function call.

Yes; I have a similar intuition for it, and agree that it's natural in that way. I'm just not sure about putting this set-membership predicate in the same syntax space as arbitrary predicates, and thereby making it a breaking change to add any new such predicates.

Could we add a new named predicate for this? set(feature, "foo") is terse and could work, though I don't love that the intuition here would probably indicate a 1:1 mapping. contains or includes are probably how we would spell this on a collection, but I think contains(feature, "foo") sounds a bit worse than plural would be contains(features, "foo").

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have an RFC together soon, though deciding what the syntax should be will definitely be better before it's fully written.

Random thought, which admittedly isn't very Rust-like, is feature?("foo"), along with feature?("foo" | "bar") and feature?("foo" & "bar"). There is some precedence in Ruby where ? means a function that returns a boolean.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some precedence in Ruby where ? means a function that returns a boolean.

It comes from Scheme, which uses the same convention for predicates, e.g. odd?.

| `!all(x, y)` | `not(all(x, y))` | `!` has lower precedence than "function call" |
| `any(!x \|\| !w, !(y && z))` | `any(any(not(x), not(w)), not(all(y, z)))` | `!`, `&&` etc. can be used inside `any`, `all` and `not` |
| `true && !false` | `all(true, not(false))` | `!`, `&&` etc. can be used on boolean literals (they are syntactically identifiers) |
| `!accessible(std::mem::forget)` | `not(accessible(std::mem::forget))` | `!`, `&&` etc. can be used on `cfg_accessible` |
| `accessible(std::a \|\| std::b)` | _syntax error_ | … but not inside |
| `!version("1.42.0")` | `not(version("1.42.0"))` | `!`, `&&` etc. can be used on `cfg_version` |
| `version(!"1.42.0")` | _syntax error_ | … but not inside |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would it interact with the target(os = "linux", ...) shorthand from RFC 3239?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well it's being removed rust-lang/rust#130780

#[cfg(all(target_os = "linux", target_arch = "arm"))]
#[cfg(target_os("linux") && target_arch("arm"))]
#[cfg(target(os = "linux", arch = "arm"))]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last comments from T-lang members tend to the opposite, so probably going to stay.


## Formal syntax

[`[cfg.syntax]`][cfg-syntax] is changed to the following:

> **<sup>Syntax</sup>**\
> _ConfigurationPredicate_ :\
> &nbsp;&nbsp; &nbsp;&nbsp; _ConfigurationOption_\
> &nbsp;&nbsp; | _ConfigurationAll_\
> &nbsp;&nbsp; | _ConfigurationAny_\
> &nbsp;&nbsp; | _ConfigurationNot_\
> &nbsp;&nbsp; | _ConfigurationAnd_\
> &nbsp;&nbsp; | _ConfigurationOr_\
> &nbsp;&nbsp; | _ConfigurationNegation_\
> &nbsp;&nbsp; | `(` _ConfigurationPredicate_ `)`
>
> _ConfigurationNegatable_ :\
> &nbsp;&nbsp; _ConfigurationOptionIdent_\
> &nbsp;&nbsp; | _ConfigurationAll_\
> &nbsp;&nbsp; | _ConfigurationAny_\
> &nbsp;&nbsp; | _ConfigurationNot_\
> &nbsp;&nbsp; | _ConfigurationNegation_ \
> &nbsp;&nbsp; | `(` _ConfigurationPredicate_ `)`
>
> _ConfigurationOptionIdent_ :\
> &nbsp;&nbsp; [IDENTIFIER]
>
> _ConfigurationOption_ :\
> &nbsp;&nbsp; [IDENTIFIER]&nbsp;(`=` ([STRING_LITERAL] | [RAW_STRING_LITERAL]))<sup>?</sup>
>
> _ConfigurationAll_\
> &nbsp;&nbsp; `all` `(` _ConfigurationPredicateList_<sup>?</sup> `)`
>
> _ConfigurationAny_\
> &nbsp;&nbsp; `any` `(` _ConfigurationPredicateList_<sup>?</sup> `)`
>
> _ConfigurationNot_\
> &nbsp;&nbsp; (`not` | `!`) `(` _ConfigurationPredicate_ `)`
>
> _ConfigurationAnd_\
> &nbsp;&nbsp; _ConfigurationPredicate_ `&&` _ConfigurationPredicate_
>
> _ConfigurationOr_\
> &nbsp;&nbsp; _ConfigurationPredicate_ `||` _ConfigurationPredicate_
>
> _ConfigurationNegation_\
> &nbsp;&nbsp; `!` _ConfigurationNegatable_
>
> _ConfigurationPredicateList_\
> &nbsp;&nbsp; _ConfigurationPredicate_ (`,` _ConfigurationPredicate_)<sup>\*</sup> `,`<sup>?</sup>

All future function-like predicates (such as `version` and `accessible`) should be added to
_ConfigurationNegatable_.

# Drawbacks
[drawbacks]: #drawbacks

- Two ways to express the same thing. This can be somewhat mitigated by a lint for the old syntax.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

- The current syntax is verbose and a relic of the past when attributes could not contain arbitrary
tokens.
- Using existing, widely-understood operators makes the syntax more familiar.
- `&` and `|` could be used instead of `&&` and `||`. Short-circuiting behavior is unobservable in
this context, so the behavior would be the same.
- `feature != "foo"` could be allowed as shorthand for `!(feature = "foo")`. This could plausibly be
interpreted as "any feature except 'foo'", which is why it is not included in this proposal.

# Prior art
[prior-art]: #prior-art

The `efg` crate is nearly identical to this proposal, the sole difference being not requiring `=`
for key-value pairs.

# Unresolved questions
[unresolved-questions]: #unresolved-questions

None so far.

# Future possibilities
[future-possibilities]: #future-possibilities

- Pattern-like syntax such as `#[cfg(feature = "foo" | "bar")]` could be allowed as a shorthand for
`#[cfg(feature = "foo" || feature = "bar")]`. This would be particularly useful for
platform-specific code (e.g. `#[cfg(target_os = "linux" | "windows")]`).