Skip to content
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

Update conditional-compilation.md #1402

Merged
merged 2 commits into from
Jul 17, 2024
Merged

Update conditional-compilation.md #1402

merged 2 commits into from
Jul 17, 2024

Conversation

klu235
Copy link
Contributor

@klu235 klu235 commented Sep 18, 2023

  • Clarify
  • Reduce redundancy

Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

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

Thanks, I appreciate the improvements!

on a configuration predicate.

It is written as `cfg`, `(`, a configuration predicate, and finally `)`.
on the given configuration predicate (_ConfigurationPredicate_ in the syntax above).
Copy link
Contributor

Choose a reason for hiding this comment

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

The original is written intentionally that way, since we agreed on a style of describing the syntax in prose in most cases, and to not defer to the grammar. Can this change be reverted?

if at least one predicate is true. If there are no predicates, it is false.
* `not()` with a configuration predicate. It is true if its predicate is false
and false if its predicate is true.
* `all()` with a comma-separated list of configuration predicates. It is true precisely if all of the given predicates are true.
Copy link
Contributor

Choose a reason for hiding this comment

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

This doesn't seem to be quite correct, since it doesn't seem to cover the empty list case (there are no true predicates in that case). Perhaps something like:

Suggested change
* `all()` with a comma-separated list of configuration predicates. It is true precisely if all of the given predicates are true.
* `all()` with a comma-separated list of configuration predicates. It is true if all of the given predicates are true, or if the list is empty.

* `not()` with a configuration predicate. It is true if its predicate is false
and false if its predicate is true.
* `all()` with a comma-separated list of configuration predicates. It is true precisely if all of the given predicates are true.
* `any()` with a comma-separated list of configuration predicates. It is true precisely if at least one of the given predicates is true.
Copy link
Contributor

Choose a reason for hiding this comment

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

Similarly:

Suggested change
* `any()` with a comma-separated list of configuration predicates. It is true precisely if at least one of the given predicates is true.
* `any()` with a comma-separated list of configuration predicates. It is true precisely if at least one of the given predicates is true. If there are no predicates, it is false.

and false if its predicate is true.
* `all()` with a comma-separated list of configuration predicates. It is true precisely if all of the given predicates are true.
* `any()` with a comma-separated list of configuration predicates. It is true precisely if at least one of the given predicates is true.
* `not()` with a configuration predicate. It is true precisely if the given predicate is false.
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't feel like brevity of words here is helping. The original seemed sufficiently brief, and seemed a little clearer to me. I would suggest keeping this as it was before.

Suggested change
* `not()` with a configuration predicate. It is true precisely if the given predicate is false.
* * `not()` with a configuration predicate. It is true if its predicate is false
and false if its predicate is true.

Comment on lines 36 to 38
_Configuration options_ are either names or key-value pairs, and are either set or
unset. Configuration options that are names, such as `unix`, are specified by simply writing them.
Configuration options that are key-value pairs are written in the form `key = "value"`, such as `target_arch = "x86_64"`.
Copy link
Contributor

Choose a reason for hiding this comment

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

The change here seems to remove some explicitness about the details of the format. That is, the words "written as a single identifier" and "Key-value pairs are written as an identifier, =, and then a string.". The text needs to explicitly say what is the syntax and form. Just mentioning an example like key = "value" isn't sufficient to define what the syntax is.

klu235 and others added 2 commits July 17, 2024 10:54
* Clarify
* Reduce redundancy
This reverts some of the changes since they were done intentionally,
and tries to improve the clarity in other areas.
Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

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

Thanks! I went ahead and pushed the suggestions.

@ehuss ehuss added this pull request to the merge queue Jul 17, 2024
Merged via the queue into rust-lang:master with commit 4d292b6 Jul 17, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants