Rollup merge of #141361 - folkertdev:varargs-cfg, r=workingjubilee

use `cfg_select!` to select the right `VaListImpl` definition

tracking issue: https://github.com/rust-lang/rust/issues/44930

Just a bit of cleanup really.

We could use `PhantomInvariantLifetime<'f>` (https://github.com/rust-lang/rust/issues/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:

- https://github.com/immunant/rust/commit/08140878fefaa4b16939b904bf825b7107069b42 original implementation
- https://github.com/immunant/rust/commit/b9ea653aee231114acbe6d4b3c7b1d692772d060 adds `VaListImpl<'f>`, but it is only covariant in `'f`
- https://github.com/rust-lang/rust/pull/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.

```rust
/// 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`

0 files changed, 0 insertions, 0 deletions