Incorrect / Inconsistent behavior of deref coercion with {}

[theemathas]

In this code, the commented-out lines fail to compile.

struct Foo;

fn f(_: &Foo) {}

fn g(_: &&Foo) {}

fn main() {
    let x: &Foo = &Box::new(Foo);
    f(x);
    f(&Box::new(Foo));
    f(&(Box::new(Foo)));
    //f(&{Box::new(Foo)});
    let y: &Foo = &Box::new(Foo);
    g(&y);
    //g(&&Box::new(Foo));
    //g(&(&Box::new(Foo)));
    g(&{&Box::new(Foo)});
}

playpen

I believe that, among other things, f(&{Box::new(Foo)}); should compile since &{Box::new(Foo)} has type &Box<Foo>, which is deref-coercible to &Foo.

Additionally, the behavior is so inconsistent that it is basically impossible to predict whether the other lines will compile without trying them.

[steveklabnik]

Whoah, &{}? I haven't seen that, though I guess it makes some degree of sense...

[steveklabnik]

Triage; no change.

[jturner314]

I came across this today while writing a macro. Until this bug gets fixed, if you're in a situation where you need deref coercion of

&{ expr }

to work correctly, a workaround is to add an extra &*, like this:

&*&{ expr }

which will then coerce correctly.

[Spoonbender]

Triage: issue still reproduces on 2021 edition, tested on rustc 1.59.0 (9d1b2106e 2022-02-23)

[theemathas]

Related or duplicate of #26978, apparently.

[pwnorbitals]

Got bitten by this today with func(&mut unsafe { *(ptr as *mut _) }), struggling to understand why a move was triggered. Needed to unnecessarily expand the unsafe block (not too bad but this was surprising)

[Noratrieb]

quoting @compiler-errors about the first example:

it has to do with how "expectations" are propagated around blocks and how we derive expectations due to & operators https://github.com/rust-lang/rust/blob/ef15976387ad9c1cdceaabf469e0cf35f5852f6d/compiler/rustc_hir_typeck/src/expr.rs#L428 fixing this will liekly unfortunately break other things