In #155697, we stabilized C-variadic function definitions (and C-variadic function declarations in traits).
While reviewing and revising the Reference PR for this, rust-lang/reference#2177, I noticed that we're stabilizing allowance of a behavior that we document as disallowed (with an immediate FCW against it). Prior to the stabilization, we gave a hard error for both of:
unsafe extern "C" fn f(...) {} // ERROR.
trait Tr {
unsafe extern "C" fn f(...); // ERROR.
}After the stabilization, these are both accepted:
#![allow(varargs_without_pattern)]
unsafe extern "C" fn f(...) {} // OK.#![allow(varargs_without_pattern)]
trait Tr {
unsafe extern "C" fn f(...); // OK.
}That is, we're accepting ... in parameter position without a preceding pattern (with a deny-by-default FCW).
This is a bit unusual for us. Normally we don't stabilize new behavior only to issue an immediately FCW. Presumably we want to ask for this to continue to give a hard error (semantically — this was already accepted in parsing).
cc @folkertdev @rust-lang/lang-docs @rust-lang/lang
In #155697, we stabilized C-variadic function definitions (and C-variadic function declarations in traits).
While reviewing and revising the Reference PR for this, rust-lang/reference#2177, I noticed that we're stabilizing allowance of a behavior that we document as disallowed (with an immediate FCW against it). Prior to the stabilization, we gave a hard error for both of:
After the stabilization, these are both accepted:
That is, we're accepting
...in parameter position without a preceding pattern (with a deny-by-default FCW).This is a bit unusual for us. Normally we don't stabilize new behavior only to issue an immediately FCW. Presumably we want to ask for this to continue to give a hard error (semantically — this was already accepted in parsing).
cc @folkertdev @rust-lang/lang-docs @rust-lang/lang