c_variadic: Add future-incompatibility warning for ... arguments without a pattern outside of extern blocks
#143619
Conversation
|
|
This comment has been minimized.
This comment has been minimized.
|
This PR changes a file inside |
|
@bors2 try for the crater |
|
Unknown command "tryfor". |
|
|
wild @bors2 try |
`c_variadic`: Make `fn f(...) {}` error like `fn f(u32) {}` outside of `extern` blocks
This PR makes unnamed `...` parameters (such as the one in `unsafe extern "C" fn f(...) {}`) a parse error to be consistent with `unsafe extern "C" fn f(u32) {}`: this is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing unnamed `...` parameters also improves the overall consistency of the Rust language by matching the treatment of other unnamed parameters. Unnamed `...` parameters in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations).
As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0:
```rust
#[cfg(any())] // Equivalent to the more recent #[cfg(false)]
unsafe extern "C" fn bar(_: u32, ...) {}
```
Since this is more or less a stability hole and is unlikely to be used in practice, I think it would be ok to break this, but this will definitely require both a crater check run and a lang FCP.
Tracking issue: #44930
cc `@folkertdev` `@workingjubilee`
r? `@joshtriplett`
|
So, should we start that crater run here? |
|
@compiler-errors could you |
|
👍 @craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚨 Report generation of 🆘 If you need assistance dealing with this failure, please ask in t-infra on Zulip |
|
not sure I have the permissions for this, but let's attempt @craterbot retry-report |
|
🛠️ Generation of the report for ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚨 Report generation of 🆘 If you need assistance dealing with this failure, please ask in t-infra on Zulip |
|
let's try again with rust-lang/crater#787 merged @craterbot retry-report |
|
🛠️ Generation of the report for ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
32f8c9a to
ab36e0a
Compare
|
Now that FCP is complete this needs review from T-compiler r? T-compiler |
|
☔ The latest upstream changes (presumably #146125) made this pull request unmergeable. Please resolve the merge conflicts. |
ab36e0a to
403dc8b
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #146185) made this pull request unmergeable. Please resolve the merge conflicts. |
403dc8b to
5dcbd08
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #146165) made this pull request unmergeable. Please resolve the merge conflicts. |
5dcbd08 to
7530b9b
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #146418) made this pull request unmergeable. Please resolve the merge conflicts. |
…without a pattern outside of `extern` blocks
7530b9b to
2891a72
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
☔ The latest upstream changes (presumably #146727) made this pull request unmergeable. Please resolve the merge conflicts. |
| /// // currently only checked after attributes are expanded, so using `#[cfg(false)]` here will | ||
| /// // allow this to compile on stable Rust. | ||
| /// #[cfg(false)] | ||
| /// fn foo(...) { |
There was a problem hiding this comment.
could you give an example of a correct usage, with a pattern?
| /// | ||
| /// Patterns are currently required for all non-`...` arguments in function definitions (with | ||
| /// some exceptions in the 2015 edition). Requiring `...` arguments to have patterns in | ||
| /// non-foreign function definitions makes the language more consistent, and removes a source of |
There was a problem hiding this comment.
like, with a block here that's "A correct usage of ... in the above example would be fn foo(_: ...) {}"
|
other than that, the changes look good (from a T-compiler POV) |
|
could you rebase on master? |
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
This PR makes
...arguments without a pattern in non-foreign functions (such as the argument inunsafe extern "C" fn f(...) {}) a future-compatibility warning; making this error would be consistent with howunsafe extern "C" fn f(u32) {}is handled. Allowing...arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the...parameter is never named and instead callingva_startis required; disallowing...arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns....arguments without a pattern inexternblocks (such asunsafe extern "C" { fn f(...); }) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations).As all the syntax gating for
c_variadichas been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0:Since this is more or less a stability hole and a Crater run shows only the
binrwcrate is using this, I think it would be ok to break this. This will require a lang FCP.The idea of rejecting
...pre-expansion was first raised here #143546 (comment).Tracking issue: #44930
cc @folkertdev @workingjubilee
r? @joshtriplett