Prototype VaList proposal
#141980
Prototype VaList proposal
#141980
Conversation
rustbot
added
A-run-make
|
This PR modifies cc @jieyouxu Some changes occurred in compiler/rustc_codegen_ssa |
beetrees
force-pushed
the
va-list-proposal
branch
from
cb90479 to
23a983d
Compare
| @@ -175,6 +175,9 @@ pub trait TyAbiInterface<'a, C>: Sized + std::fmt::Debug { | |||
| fn is_tuple(this: TyAndLayout<'a, Self>) -> bool; | |||
| fn is_unit(this: TyAndLayout<'a, Self>) -> bool; | |||
| fn is_transparent(this: TyAndLayout<'a, Self>) -> bool; | |||
| /// Returns `true` if the type is always passed indirectly. Currently only | |||
| /// used for `VaList`s. | |||
| fn is_pass_indirectly(this: TyAndLayout<'a, Self>) -> bool; | |||
There was a problem hiding this comment.
I only see this as having an effect on x86-64 and aarch64, but doesn't the argument-passing algorithm already enforce this by making sure that VaList gets passed via Memory?
There was a problem hiding this comment.
This method is only needed by the code in rustc_target::callconv to ensure that VaList gets PassMode::Indirect { on_stack: false, .. }. repr_options_of_def sets the PASS_INDIRECTLY ReprFlag for VaList when it needs to be passed indirectly for non-rustic ABIs, however there is no way to directly access ReprFlags from the calling convention code. There is already a method is_transparent on TyAbiInterface to expose the IS_TRANSPARENT ReprFlag, so I used a similar pattern to expose PASS_INDIRECTLY to the calling convention code. Without this method, the System V x86-64 ABI would pass VaList with PassMode::Indirect { on_stack: true, .. }.
There was a problem hiding this comment.
And just to finish the thought: the difference is important (only) in an FFI context: a foreign extern "C" { fn(ap: VaList); } would expect ap to be passed as PassMode::Indirect { on_stack: false, .. }
#141524 (comment)
r? @ghost