Revert "Stabilize extended_varargs_abi_support"#136897
Conversation
This reverts commit 685f189.
|
Note that even if this is accepted I intend to almost immediately relaunch the stabilization process here for the set of ABIs for which it is simply and obviously consistent to do this for... which is basically everything except |
WaffleLapkin
left a comment
There was a problem hiding this comment.
r=me with/without nitpick
| (accepted, expr_fragment_specifier_2024, "1.83.0", Some(123742)), | ||
| /// Allows arbitrary expressions in key-value attributes at parse time. | ||
| (accepted, extended_key_value_attributes, "1.54.0", Some(78835)), | ||
| /// Allows using `efiapi`, `aapcs`, `sysv64` and `win64` as calling |
There was a problem hiding this comment.
fun how this doesn't even mention "system"...
And leave a comment on the unusual `cfg_attr` Co-authored-by: waffle <waffle.lapkin@gmail.com>
5b51fd7 to
cafa646
Compare
|
@bors r+ |
|
@bors p=5 this needs to be beta backported before Friday, so let's try to merge this as soon as possible |
Maybe |
|
That would work as quick fix but ideally it should return the same as whatever calling convention |
|
☀️ Test successful - checks-actions |
|
I'll unilaterally beta accept this - reverting a stabilization feels like obviously required to backport. |
|
Note, we should include the reference revert too: rust-lang/reference#1734 |
I cannot find an FCP for this, despite it being a stabilization PR which normally means we do an FCP of some kind? It would seem reasonable for either compiler or lang to have FCPed it? I am thus opening a revert PR, which mostly-cleanly applies, so that we can later actually land this properly with a stability report and FCP.
extended_varargs_abi_supportwithout FCP? #136896extended_varargs_abi_support#116161extended_varargs_abi_support#100189