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.

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

Jump to bottom

Disallow incoherent cfgs #610

Closed
1 of 3 tasks
jyn514 opened this issue Apr 6, 2023 · 3 comments
Closed
1 of 3 tasks

Disallow incoherent cfgs #610

jyn514 opened this issue Apr 6, 2023 · 3 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@jyn514
Copy link
Member

jyn514 commented Apr 6, 2023 •
edited
Loading

Proposal

Disallow combinations of flags that don't make sense. Here is a non-exhaustive list:

  • --cfg debug_assertions -C debug-assertions=off
  • --cfg unix --target x86_64-pc-windows-msvc (and similar for --cfg windows, --cfg target_arch=..., target_os, etc)
  • --cfg test without --test
  • --cfg proc_macro --crate-type lib
  • --cfg panic=abort -C panic=unwind

I don't see any other cfgs in https://doc.rust-lang.org/reference/conditional-compilation.html, but I'm unsure if that's because there are no others or the reference just isn't up to date. The implementation PR should verify that this is an exhaustive list (once all the target_* cfgs are included).

Note that this is technically a breaking change, but in practice any code that is using these combinations of flags is already hopelessly broken. I am of course happy to do a crater run to verify that's true.

Alternatives

Disallow --cfg debug_assertions etc. even if -C debug-assertions=on is set. This seems unnecessary, since the meaning is clear, and would be a larger breaking change.

Mentors or Reviewers

I am not sure who should mentor this work, but the code itself should be fairly simple.

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
@jyn514 jyn514 added major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team labels Apr 6, 2023
@rustbot
Copy link
Collaborator

rustbot commented Apr 6, 2023

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Apr 6, 2023
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Apr 13, 2023
@jyn514 jyn514 mentioned this issue Apr 20, 2023
Merged
@pnkfelix
Copy link
Member

pnkfelix commented Jun 9, 2023

@rustbot second

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Jun 9, 2023
@apiraino
Copy link
Contributor

apiraino commented Jul 6, 2023

@rustbot label -final-comment-period +major-change-accepted

@apiraino apiraino closed this as completed Jul 6, 2023
@rustbot rustbot added major-change-accepted A major change proposal that was accepted to-announce Announce this issue on triage meeting and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Jul 6, 2023
@est31 est31 mentioned this issue Jul 6, 2023
Closed
3 tasks
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jul 6, 2023
@WesleyRosenblum WesleyRosenblum mentioned this issue Oct 12, 2023
Open
@Urgau Urgau mentioned this issue Jun 8, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 26, 2024
@matthiaskrgr
Rollup merge of rust-lang#126158 - Urgau:disallow-cfgs, r=petrochenkov
af11efc 
Disallow setting some built-in cfg via set the command-line

This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.

This implements MCP rust-lang/compiler-team#610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.

~~In order to not break the world I only included cfgs that didn't seems to be manually set by doing a Github Search and looking at all the results. We may still want to a warn about them in future but this isn't part of this PR.~~

------

The `unexpected_builtin_cfgs` lint detects builtin cfgs set via the CLI, `--cfg`.

*(deny-by-default)*

### Example

```text
rustc --cfg unix
```

```rust,ignore (needs command line option)
fn main() {}
```

This will produce:

```text
error: unexpected `--cfg unix` flag
  |
  = note: config `unix` is only supposed to be controlled by `--target`
  = note: see <https://github.com/rust-lang/rust/issues/xxxxx> for more information
  = note: `#[deny(unexpected_builtin_cfgs)]` on by default
```

### Explanation

Setting builtin cfgs can and does produce incoherent behavior, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.

-----

r? `@petrochenkov`
cc `@jyn514`
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 5, 2024
@bors
Auto merge of rust-lang#126158 - Urgau:disallow-cfgs, r=petrochenkov
968d0ac 
Disallow setting some built-in cfg via set the command-line

This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.

This implements MCP rust-lang/compiler-team#610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.

------

The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.

*(deny-by-default)*

### Example

```text
rustc --cfg unix
```

```rust,ignore (needs command line option)
fn main() {}
```

This will produce:

```text
error: unexpected `--cfg unix` flag
  |
  = note: config `unix` is only supposed to be controlled by `--target`
  = note: manually setting a built-in cfg can and does create incoherent behaviours
  = note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
```

### Explanation

Setting builtin cfgs can and does produce incoherent behaviour, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.

-----

r? `@petrochenkov`
cc `@jyn514`
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 7, 2024
@bors
Auto merge of rust-lang#126158 - Urgau:disallow-cfgs, r=petrochenkov
dd4b695 
Disallow setting some built-in cfg via set the command-line

This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.

This implements MCP rust-lang/compiler-team#610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.

------

The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.

*(deny-by-default)*

### Example

```text
rustc --cfg unix
```

```rust,ignore (needs command line option)
fn main() {}
```

This will produce:

```text
error: unexpected `--cfg unix` flag
  |
  = note: config `unix` is only supposed to be controlled by `--target`
  = note: manually setting a built-in cfg can and does create incoherent behaviours
  = note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
```

### Explanation

Setting builtin cfgs can and does produce incoherent behaviour, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.

-----

r? `@petrochenkov`
cc `@jyn514`
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 7, 2024
@bors
Auto merge of rust-lang#126158 - Urgau:disallow-cfgs, r=petrochenkov
a198c03 
Disallow setting some built-in cfg via set the command-line

This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.

This implements MCP rust-lang/compiler-team#610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.

------

The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.

*(deny-by-default)*

### Example

```text
rustc --cfg unix
```

```rust,ignore (needs command line option)
fn main() {}
```

This will produce:

```text
error: unexpected `--cfg unix` flag
  |
  = note: config `unix` is only supposed to be controlled by `--target`
  = note: manually setting a built-in cfg can and does create incoherent behaviours
  = note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
```

### Explanation

Setting builtin cfgs can and does produce incoherent behaviour, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.

-----

r? `@petrochenkov`
cc `@jyn514`
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 7, 2024
@bors
Auto merge of rust-lang#126158 - Urgau:disallow-cfgs, r=<try>
ac7969d 
Disallow setting some built-in cfg via set the command-line

This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.

This implements MCP rust-lang/compiler-team#610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.

------

The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.

*(deny-by-default)*

### Example

```text
rustc --cfg unix
```

```rust,ignore (needs command line option)
fn main() {}
```

This will produce:

```text
error: unexpected `--cfg unix` flag
  |
  = note: config `unix` is only supposed to be controlled by `--target`
  = note: manually setting a built-in cfg can and does create incoherent behaviours
  = note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
```

### Explanation

Setting builtin cfgs can and does produce incoherent behaviour, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.

-----

r? `@petrochenkov`
cc `@jyn514`

try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
try-job: dist-various-1
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 7, 2024
@bors
Auto merge of rust-lang#126158 - Urgau:disallow-cfgs, r=petrochenkov
ce20e15 
Disallow setting some built-in cfg via set the command-line

This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.

This implements MCP rust-lang/compiler-team#610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.

------

The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.

*(deny-by-default)*

### Example

```text
rustc --cfg unix
```

```rust,ignore (needs command line option)
fn main() {}
```

This will produce:

```text
error: unexpected `--cfg unix` flag
  |
  = note: config `unix` is only supposed to be controlled by `--target`
  = note: manually setting a built-in cfg can and does create incoherent behaviours
  = note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
```

### Explanation

Setting builtin cfgs can and does produce incoherent behaviour, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.

-----

r? `@petrochenkov`
cc `@jyn514`

try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
try-job: dist-various-1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@pnkfelix @apiraino @jyn514 @rustbot