use cfg_select! to select the right VaListImpl definition

[folkertdev]

tracking issue: #44930

Just a bit of cleanup really.

We could use PhantomInvariantLifetime<'f> (#135806) to make it more precise what that PhantomData<&'f mut &'f c_void> marker is doing. I'm not sure how ready that feature is though, @jhpratt are these types good to use internally?

---

Some research into the lifetimes of VaList and VaListImpl:

It's easy to see why the lifetime of these types should not be extended, a VaList or VaListImpl escaping its function is a bad idea. I don't currently see why coercing the lifetime to a shorter lifetime is problematic though, but probably I just don't understand variance well enough to see it. The history does not provide much explanation:

• immunant@0814087 original implementation
• immunant@b9ea653 adds VaListImpl<'f>, but it is only covariant in 'f
• Make VaListImpl<'f> invariant over the 'f lifetime #62639 makes VaListImpl<'f> invariant over 'f (because VaList<'a, 'f> is already invariant over 'f, but I think that is just an implementation detail?)

Beyond that I don't see how the lifetime situation can be simplified significantly, e.g. this function really needs 'copy to be unconstrained.

/// Copies the `va_list` at the current location.
pub unsafe fn with_copy<F, R>(&self, f: F) -> R
where
    F: for<'copy> FnOnce(VaList<'copy, 'f>) -> R,
{
    let mut ap = self.clone();
    let ret = f(ap.as_va_list());
    // SAFETY: the caller must uphold the safety contract for `va_end`.
    unsafe {
        va_end(&mut ap);
    }
    ret
}

@rustbot label +F-c_variadic
r? @workingjubilee

[folkertdev]

I'm confused by this implementation that is used when we don't know the layout of va_list (the _ => { ... } case in the cfg_match! above). It is inconsistent with the others.

Could we not have &'a mut VaListImpl<'f> here like above, and make the VaListImpl a ZST containing just the invariance marker?

Is that fallback implementation even meaningful?

[folkertdev]

Ok no, after reading a bit more there are just two approaches

1. va_list is just an opaque pointer (probably just the next variadic argument on the stack, though it's opaque so we can't know)
2. va_list is some sort of struct. It looks like this is used when registers are also at play for passing variadic arguments

These two approaches are captured by the two different ways of representing VaList. I added a comment with some of that information, in particular #56599 had some useful info.

[folkertdev]

That does raise the question: what is VaList for? it has no methods of its own, so I don't see its purpose.

[bjorn3]

VaList is supposed to be ABI compatible with C's va_list

[folkertdev]

Yes, I was confused by the C definition, until I rediscovered that nasty thing where sizeof in C is not the same as size_of in rust: for arrays, sizeof gives the length of the array, though it is really used/passed as a pointer type.

Anyway, #44930 (comment) has an updated design for this api, which keeps VaListImpl private.

[folkertdev]

blocked on #137198 for now, which renames cfg_match! tocfg_select!.

edit: that was merged, we're good to go here.

[jhpratt]

I don't see any reason not to use the new marker types when appropriate. That's what they're there for, after all.

[workingjubilee]

looks fine to me.
@bors r+

[bors]

📌 Commit 89a8abc has been approved by workingjubilee

It is now in the queue for this repository.