Bad diagnostics when constructing tuple variant with static ref inside const

[juntyr]

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=faa286146f7760bc7c1be85eaac73f9d

const OPTIONAL_SLICE_V1: Option<&'static [u8]> = Some(&{
    let array = [1, 2, 3];
    array
});

The current output is (both on stable, beta, and nightly):

error[[E0716]](https://doc.rust-lang.org/stable/error-index.html#E0716): temporary value dropped while borrowed
 --> src/lib.rs:1:56
  |
1 |    const OPTIONAL_SLICE_V1: Option<&'static [u8]> = Some(&{
  |   __________________________________________________-_____^
  |  |__________________________________________________|
  | ||
2 | ||     let array = [1, 2, 3];
3 | ||     array
4 | || });
  | || ^-
  | || ||
  | ||_|temporary value is freed at the end of this statement
  |  |_|using this value as a constant requires that borrow lasts for `'static`
  |    creates a temporary which is freed while still in use

For more information about this error, try `rustc --explain E0716`.

It is, however, possible to get this code to compile by using the struct initialiser syntax for the tuple variant:

const OPTIONAL_SLICE_V2: Option<&'static [u8]> = Some {
    0: &{
        let array = [1, 2, 3];
        array
    },
};

Given that this initialiser isn't used very often, it took me a while to remember it as an alternative and to figure out that the use of Some as a function was causing the error.

Ideally, the error message should also suggest something like

help: try using a struct initializer instead: `Some { 0: ... }`

Uhm... I don't think that should even be possible that one initialization syntax works and the other doesn't, especially in this case. I feel like this might be an actual compiler bug rather than just a diagnostic issue. :P

[compiler-errors]

I haven't looked too much in to this, but I would guess it's because TupleStruct(x, y, z) is treated more like a function call than a struct constructor expression, and it's very likely (I would even guess in backwards-compatible terms) to make the former act like the latter, I think..

It might be worth experimenting, but certainly any fix would need some root-cause explanation and a crater run to verify that it doesn't break other things.

[QuineDot]

const blocks are another workaround.

const OPTIONAL_SLICE_V3: Option<&'static [u8]> = Some(& const {
    let array = [1, 2, 3];
    array
});

const OPTIONAL_SLICE_V4: Option<&'static [u8]> = Some(const { &{
    let array = [1, 2, 3];
    array
}});

---

This comes up more readily when a const-constructable type with a destructor is involved, because those aren't eligible for constant promotion. See this URLO topic.

enum WithDestructor {
    A,
    // Comment this variant and it compiles
    B(String),
}

impl WithDestructor {
    const fn new() -> Self {
        Self::A
    }
}

// error[E0493]: destructor of `WithDestructor` cannot be evaluated at compile-time
const OPT: Option<&WithDestructor> = Some(&WithDestructor::new());

// These versions compile
const BLOCK: Option<&WithDestructor> = Some(const { &WithDestructor::new() });
const STRUCT_LITERAL: Option<&WithDestructor> = Some {
    0: &WithDestructor::new()
};

Playground.

[estebank]

Triage: The original code now compiles.