Description
Mostly this is just an infodump, because I'm not sure how to fix this one.
The tests/ui/delegation/fn-header.rs test fails because these two functions are not implemented.
fn va_start(&mut self, _va_list: RValue<'gcc>) -> RValue<'gcc> {
unimplemented!();
}
fn va_end(&mut self, _va_list: RValue<'gcc>) -> RValue<'gcc> {
unimplemented!();
}It's slightly surprising to me that this is the only test that fails for that reason. There are plenty of other tests that also use C varargs, and they apparently don't cause issues (and don't hit these functions). The test does use incomplete features (fn_delegation), but I don't immediately see why that is relevant. I think these functions should just work.
Anyway, implementing them appears straightforward (the llvm backend does something similar).
fn va_start(&mut self, va_list: RValue<'gcc>) -> RValue<'gcc> {
let func = self.context.get_builtin_function("__builtin_va_start");
self.context.new_call(self.location, func, &[va_list])
}
fn va_end(&mut self, va_list: RValue<'gcc>) -> RValue<'gcc> {
let func = self.context.get_builtin_function("__builtin_va_end");
self.context.new_call(self.location, func, &[va_list])
}However, this still fails because
thread 'rustc' panicked at /home/folkertdev/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/gccjit-2.5.0/src/context.rs:1131:17:
unimplemented primitive type for builtin (type: BT_VALIST_REF)
which I believe is because BT_VALIST_REF (and likely also BT_VALIST_ARG) are unimplemented:
case BT_CONST_STRING: return m_ctxt->get_type (GCC_JIT_TYPE_CONST_CHAR_PTR);
// case BT_DFLOAT32:
// case BT_DFLOAT64:
// case BT_DFLOAT128:
// case BT_VALIST_REF:
// case BT_VALIST_ARG:
case BT_I1: return m_ctxt->get_int_type (1, true);
case BT_I2: return m_ctxt->get_int_type (2, true);That's where my knowledge stops. An LLM suggested that a void pointer might work, but I have no idea whether that is accurate (or how to even evaluate whether that is in fact correct).