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

bootstrap: compactify --check-cfg arguments #98080

Closed
wants to merge 1 commit into from

Conversation

est31
Copy link
Member

@est31 est31 commented Jun 14, 2022

The current code creates more --check-cfg arguments than needed,
especially one argument per bare name. To save arguments,
we now collect the name specific arguments into one.

Before, the code this commit changes would have generated
these arguments for a typical compiler crate:

'--check-cfg=values(bootstrap)' '--check-cfg=values(parallel_compiler)' '--check-cfg=values(no_btreemap_remove_entry)' '--check-cfg=values(crossbeam_loom)' '--check-cfg=values(span_locations)'

Now it generates:

'--check-cfg=names(bootstrap,parallel_compiler,no_btreemap_remove_entry,crossbeam_loom,span_locations)'

The current code creates more --check-cfg arguments than needed,
especially one argument per bare name. To save arguments,
we now collect the name specific arguments into one.

Before, the code this commit changes would have generated
these arguments for a typical compiler crate:

    '--check-cfg=values(bootstrap)' '--check-cfg=values(parallel_compiler)' '--check-cfg=values(no_btreemap_remove_entry)' '--check-cfg=values(crossbeam_loom)' '--check-cfg=values(span_locations)'

Now it generates:

    '--check-cfg=names(bootstrap,parallel_compiler,no_btreemap_remove_entry,crossbeam_loom,span_locations)'
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 14, 2022
@est31
Copy link
Member Author

est31 commented Jun 14, 2022

cc @Urgau

@est31 est31 mentioned this pull request Jun 14, 2022
@Urgau
Copy link
Member

Urgau commented Jun 14, 2022

Those are not equivalent, values(bootstrap) state that a key named bootstrap exist and that no values are associated with it and names(bootstrap) state that a key named bootstrap exist but we know nothing about the possible values associated with it. (Note: this is a little simplified because there could have been values inserted previously, but that's not the case here).

This change would allow someone to mistakenly write cfg(bootstrap = "test") without being detected, while it's currently detected as being unexpected and produce an error.

@est31
Copy link
Member Author

est31 commented Jun 14, 2022

Oh I see, I've thought they were. Thanks for your explanation. I wonder if there could be a flags() next to names() and values() as a shorthand for many values(...) calls. Personally, I feel that most cfg attrs in the wild are binary yes/no things so one should support them in a nicer fashion.

@Urgau
Copy link
Member

Urgau commented Jun 15, 2022

I wonder if there could be a flags() next to names() and values() as a shorthand for many values(...) calls. Personally, I feel that most cfg attrs in the wild are binary yes/no things so one should support them in a nicer fashion.

Maybe, but I don't think it's a big issue, most projects that will need to manually set --check-cfg args will only have a small number (<=2 ?) so I don't think it would be problematic to have multiples args; there isn't a way to do this with --cfg.

Also as we can see here the syntax implication is already not simple and I fear that adding another thing will only make things worse not better.

@jyn514
Copy link
Member

jyn514 commented Jun 17, 2022

I see both names() and values() in the diff. What's the state of this PR? Is it possible to use a shorter syntax while keeping the same meaning or should it just be closed?

@jyn514 jyn514 assigned jyn514 and unassigned Mark-Simulacrum Jun 17, 2022
@jyn514 jyn514 added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) C-cleanup Category: PRs that clean code up or issues documenting cleanup. labels Jun 17, 2022
@jyn514
Copy link
Member

jyn514 commented Jun 17, 2022

(I agree with @Urgau that making the invocation slightly shorter doesn't seem worth making the syntax more complicated.)

@jyn514 jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 17, 2022
@est31 est31 closed this Jun 18, 2022
@est31
Copy link
Member Author

est31 commented Jun 18, 2022

Yeah let's close this. I'm still not happy about it, and the difference is only that values() also checks that you don't do #[cfg(bootstrap = "yes")], which is way less likely to happen than a typo like #[cfg(botstrap)] or something. So it's only a detail but I guess it's not that costly to have the longer invocation...

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 17, 2023
…ochenkov

Add new simpler and more explicit syntax for check-cfg

<details>
<summary>
Old proposition (before the MCP)
</summary>

This PR adds a new simpler and more explicit syntax for check-cfg. It consist of two new form:
 - `exhaustive(names, values)`
 - `configure(name, "value1", "value2", ... "valueN")`

The preview forms `names(...)` and `values(...)` have implicit meaning that are not strait-forward. In particular `values(foo)`&`values(bar)` and `names(foo, bar)` are not equivalent which has created [some confusions](rust-lang#98080).

Also the `names()` and `values()` form are not clear either and again created some confusions where peoples believed that `values()`&`values(foo)` could be reduced to just `values(foo)`.

To fix that the two new forms are made to be explicit and simpler. See the table of correspondence:
  - `names()` -> `exhaustive(names)`
  - `values()` -> `exhaustive(values)`
  - `names(foo)` -> `exhaustive(names)`&`configure(foo)`
  - `values(foo)` -> `configure(foo)`
  - `values(feat, "foo", "bar")` -> `configure(feat, "foo", "bar")`
  - `values(foo)`&`values(bar)` -> `configure(foo, bar)`
  - `names()`&`values()`&`values(my_cfg)` -> `exhaustive(names, values)`&`configure(my_cfg)`

Another benefits of the new syntax is that it allow for further options (like conditional checking for --cfg, currently always on) without syntax change.

The two previous forms are deprecated and will be removed once cargo and beta rustc have the necessary support.

</details>

This PR is the first part of the implementation of [MCP636 - Simplify and improve explicitness of the check-cfg syntax](rust-lang/compiler-team#636).

## New `cfg` form

It introduces the new [`cfg` form](rust-lang/compiler-team#636) and deprecate the other two:
```
rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))'
```

## Default built-in names and values

It also changes the default for the built-in names and values checking.

 - Built-in values checking would always be activated as long as a `--check-cfg` argument is present
 - Built-in names checking would always be activated as long as a `--check-cfg` argument is present **unless** if any `cfg(any())` arg is passed

~~**Note: depends on rust-lang#111068 but is reviewable (last two commits)!**~~

Resolve rust-lang/compiler-team#636

r? `@petrochenkov`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 17, 2023
Rollup merge of rust-lang#111072 - Urgau:check-cfg-new-syntax, r=petrochenkov

Add new simpler and more explicit syntax for check-cfg

<details>
<summary>
Old proposition (before the MCP)
</summary>

This PR adds a new simpler and more explicit syntax for check-cfg. It consist of two new form:
 - `exhaustive(names, values)`
 - `configure(name, "value1", "value2", ... "valueN")`

The preview forms `names(...)` and `values(...)` have implicit meaning that are not strait-forward. In particular `values(foo)`&`values(bar)` and `names(foo, bar)` are not equivalent which has created [some confusions](rust-lang#98080).

Also the `names()` and `values()` form are not clear either and again created some confusions where peoples believed that `values()`&`values(foo)` could be reduced to just `values(foo)`.

To fix that the two new forms are made to be explicit and simpler. See the table of correspondence:
  - `names()` -> `exhaustive(names)`
  - `values()` -> `exhaustive(values)`
  - `names(foo)` -> `exhaustive(names)`&`configure(foo)`
  - `values(foo)` -> `configure(foo)`
  - `values(feat, "foo", "bar")` -> `configure(feat, "foo", "bar")`
  - `values(foo)`&`values(bar)` -> `configure(foo, bar)`
  - `names()`&`values()`&`values(my_cfg)` -> `exhaustive(names, values)`&`configure(my_cfg)`

Another benefits of the new syntax is that it allow for further options (like conditional checking for --cfg, currently always on) without syntax change.

The two previous forms are deprecated and will be removed once cargo and beta rustc have the necessary support.

</details>

This PR is the first part of the implementation of [MCP636 - Simplify and improve explicitness of the check-cfg syntax](rust-lang/compiler-team#636).

## New `cfg` form

It introduces the new [`cfg` form](rust-lang/compiler-team#636) and deprecate the other two:
```
rustc --check-cfg 'cfg(name1, ..., nameN, values("value1", "value2", ... "valueN"))'
```

## Default built-in names and values

It also changes the default for the built-in names and values checking.

 - Built-in values checking would always be activated as long as a `--check-cfg` argument is present
 - Built-in names checking would always be activated as long as a `--check-cfg` argument is present **unless** if any `cfg(any())` arg is passed

~~**Note: depends on rust-lang#111068 but is reviewable (last two commits)!**~~

Resolve rust-lang/compiler-team#636

r? `@petrochenkov`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants