Repository navigation
Tracking Issue for extern_system_varargs #136946
Description
This is a tracking issue for enabling using an extern "system" function with varargs.
The feature gate for the issue is #![feature(extern_system_varargs)].
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
- Implementation
- Adjust documentation (see instructions on rustc-dev-guide)
- Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
- should
extern "system"work with varargs at all? it translates toextern "stdcall"on x86, which does not? while MSVC sometimes translates__stdcallto be identical to the C ABI, we have previously rejected implementing MSVC's oddities:
Activity
Rollup merge of rust-lang#136948 - workingjubilee:split-off-extern-sy…
Rollup merge of rust-lang#136948 - workingjubilee:split-off-extern-sy…
Unrolled build for rust-lang#136948
RalfJung commentedon Feb 14, 2025
You keep saying this and I keep correcting you.^^
We have implemented their oddities on Windows targets: stdcall works on x86_64-pc-windows-msvc and even aarch64-pc-windows-msvc. There was some discussion about this here and here.
workingjubilee commentedon Feb 14, 2025
Yes yes, I copied some text around, so you get to copy some text around too.
If
extern "stdcall"is downgraded toextern "C"anyways when variable arguments are involved on MSVC targets, why doesn't that apply toextern "stdcall"for all cases where the ABI is supported?workingjubilee commentedon Feb 14, 2025
At least if we did that, it would be... well, absurd, I think, but equally absurd in all cases?
RalfJung commentedon Feb 14, 2025
I don't understand the question / proposal. This does apply in all cases, no?
ChrisDenton commentedon Feb 14, 2025
That is not true for the
raw-dylibfeature, which is stricter.workingjubilee commentedon Feb 14, 2025
Currently
rustc_hir_analysiswill reject an attempt to use a variable argument function withextern "stdcall", such asextern "stdcall" fn(i32, ...), without further consideration.RalfJung commentedon Feb 14, 2025
I guess the argument is that MSVC accepts varagrs for
systembut not forstdcall? Or is that not correct?Oh, that is an odd inconsistency... I filed a separate issue for that: #137018.
workingjubilee commentedon Feb 14, 2025
extern "system"is a Rust invention, as far as I am aware.Rollup merge of #136948 - workingjubilee:split-off-extern-system-vara…
RalfJung commentedon Feb 20, 2025
Ah, right.
In my understanding,
extern "system"is a "do the right thing" ABI, mainly for calling system functions on Windows -- and there are variadic system functions on Windows. So IMO we should support variadics for that ABI and ensure it works the way the Windows ABI does (for win32 targets, which is the only target where there's even a question about what this should do). That seems like the most convenient thing to do.RalfJung commentedon Feb 20, 2025
@workingjubilee the main argument against supporting varargs here seems to be that the implementation is ugly, or did I misunderstand that? Given everything going on during ABI adjustments, it's a bit surprising to me that taking into account whether a function is variadic would cause so much trouble.
Soveu commentedon May 17, 2025
Hi, do I understand correctly that this feature got separated from
extended_varargs_abi_supportand we could attempt stabilization of it again?RalfJung commentedon Jun 12, 2025
@Soveu we could attempt stabilization of #100189 -- I think that feature is entirely uncontroversial, it just needs someone to write a stabilization report.
For this one, @workingjubilee had reservations about making "system" fall back to "C" when there are variadics. Meanwhile however, we have landed #141569 and made it compatible with that behavior. Jubilee, are you still opposed to stabilizing "system" variadics as-is or can you live with it now?
workingjubilee commentedon Jun 12, 2025
I think there are desirable simplifications still from not having this behavior however I am increasingly reconsidering my reservations, yes, if we are also moving to being "maximally strict" on all other fronts re: usage of ABI strings. I don't think that makes much sense without
extern "system"adopting a fully "do what I mean" semantic.RalfJung commentedon Jun 12, 2025
In that case it may make sense for someone to prepare a stabilization report and check test coverage for this.
RalfJung commentedon Jul 17, 2025
I am proposing this for stabilization in #144066.
Rollup merge of rust-lang#144066 - RalfJung:extern-c-variadics, r=wor…
Rollup merge of rust-lang#144066 - RalfJung:extern-c-variadics, r=wor…
Unrolled build for #144066
Rollup merge of #144066 - RalfJung:extern-c-variadics, r=workingjubilee
Rollup merge of rust-lang#144066 - RalfJung:extern-c-variadics, r=wor…