support c-variadic functions in rustc_const_eval

[folkertdev]

tracking issue: #44930

The new GlobalAlloc::VaList is used to create an AllocId that represents the variable argument list of a frame. The allocation itself does not store any data, all we need is the unique identifier.

The actual variable argument list is stored in Memory, and keyed by the AllocId. The Frame also stores this AllocId, so that when a frame is popped, it can deallocate the variable arguments.

At "runtime" a VaList value stores a pointer to the global allocation in its first bytes. The provenance on this pointer can be used to retrieve its AllocId, and the offset of the pointer is used to store the index of the next argument to read from the variable argument list.

Miri does not yet support va_arg, but I think that can be done separetely?

r? @RalfJung
cc @workingjubilee

[rust-bors]

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[rust-bors]

☔ The latest upstream changes (presumably #146923) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

⚠️ #[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[RalfJung]

I think there's only one actual discussion left, the rest are just comment nits.

View changes since this review

[RalfJung]

I am still quite confused by this comment -- this doesn't seem to do anything to "handle" any kind of extra argument. The handling of that happens below, at the requires_caller_location call. It's not clear to me what you are trying to say here.

[folkertdev]

The fixed_count does not include the extra track_caller argument (i.e. fixed_count != callee_fn_abi.len(). Thus, if you'd only create an iterator over the first fixed_count arguments, you'd skip that track_caller argument, and the unwrap in this block below the loop will panic

            // If the callee needs a caller location, pretend we consume one more argument from the ABI.
            if instance.def.requires_caller_location(*self.tcx) {
                callee_args_abis.next().unwrap();
            }

[folkertdev]

I changed the "this handles" into "this iterator includes", hope that clarifies things?

[RalfJung]

This seems to be the corresponding codegen code:

rust/compiler/rustc_codegen_ssa/src/mir/block.rs

Lines 1102 to 1113 in 29ed211

	let sig = callee.layout.ty.fn_sig(bx.tcx());
	let extra_args = &args[sig.inputs().skip_binder().len()..];
	let extra_args = bx.tcx().mk_type_list_from_iter(extra_args.iter().map(|op_arg| {
	let op_ty = op_arg.node.ty(self.mir, bx.tcx());
	self.monomorphize(op_ty)
	}));
	let fn_abi = match instance {
	Some(instance) => bx.fn_abi_of_instance(instance, extra_args),
	None => bx.fn_abi_of_fn_ptr(sig, extra_args),
	};

It does not need any such matches!. So what is different here?