It should be possible to get a mutable reference to a ZST literal

[joshlf]

The following code is legal:

fn get_mut_ref<'a>() -> &'a mut [u8] {
    &mut []
}

However, if we instead use (), it's no longer legal:

fn get_mut_ref<'a>() -> &'a mut () {
    &mut ()
}

We get this error:

error[E0515]: cannot return reference to temporary value
 --> src/lib.rs:2:5
  |
2 |     &mut ()
  |     ^^^^^--
  |     |    |
  |     |    temporary value created here
  |     returns a reference to data owned by the current function

Is there a reason that the former is legal while the latter is not? I would expect the latter to be legal - in the general case, it'd be great if it were legal for any ZST, although I'm sure that's more complicated (especially in a generic context).

On Fuchsia, we're currently using this hack to work around this limitation.

[shamatar]

I had a similar issue, it also works with shorter hack

fn get_mut_ref<'a>() -> &'a mut () {
    static mut _HACK: () = ();

    unsafe {&mut _HACK}
}

that produces almost the same assembly as another accepted example

fn get_mut_ref_array<'a>() -> &'a mut [u8; 0] {
    &mut []
}

[Rageking8]

@rustbot label +A-zst +T-types

[ds84182]

This seems to work well for ZSTs.

fn get_mut_ref<'a>() -> &'a mut () { Box::leak(Box::new(())) }

Does not actually invoke the allocator. Instead returns a properly aligned dangling ref.

[RalfJung]

That this works for empty arrays is maintained for backwards compatibility, since this was allowed in some very early version of promotion.

I think we could plausibly allow this for more / all ZST. Cc @oli-obk

[oli-obk]

yea, seems ok to add more

[joshlf]

Does anyone have a sense of what it would take to implement this (technically)? Also, from a process perspective, I assume this is simple enough that it could just be a PR + FCP (rather than a full RFC)?

[RalfJung]

The check for this is here:

rust/compiler/rustc_const_eval/src/transform/promote_consts.rs

Lines 470 to 484 in 866710c

	BorrowKind::Mut { kind: MutBorrowKind::Default | MutBorrowKind::TwoPhaseBorrow } => {
	let ty = place.ty(self.body, self.tcx).ty;
	// In theory, any zero-sized value could be borrowed
	// mutably without consequences. However, only &mut []
	// is allowed right now.
	if let ty::Array(_, len) = ty.kind() {
	match len.try_eval_target_usize(self.tcx, self.param_env) {
	Some(0) => {}
	_ => return Err(Unpromotable),
	}
	} else {
	return Err(Unpromotable);
	}
	}

It needs to be adjusted to detect more zero-sized types. This is polymorphic code so we can't just compute the layout, we have to actually traverse the type. Not sure if such an analysis to predict whether a type is a ZST already exists.

And yeah I assume FCP will suffice.

[oli-obk]

Once the naive layout logic lands again, we could probably use it for this, too

[joshlf]

Thanks for the details, @RalfJung!

Once the naive layout logic lands again, we could probably use it for this, too

@oli-obk, are there any docs/PRs I can read about this?

[RalfJung]

Naive layout was part of #113166 but the PR got reverted

[joshlf]

Awesome, thanks! Is re-landing naive layout tracked anywhere?

[oli-obk]

I don't know what @moulins plan is, no one else is working on it.