c_variadic
: Make fn f(...) {}
error like fn f(u32) {}
outside of extern
blocks
#143619
+348
−166
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR makes unnamed
...
parameters (such as the one inunsafe extern "C" fn f(...) {}
) a parse error to be consistent withunsafe extern "C" fn f(u32) {}
: this is a source of confusion for programmers coming from C, where the...
parameter is never named and instead callingva_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 inextern
blocks (such asunsafe 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: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