"unimplemented constant expression: tuple struct constructors" for NonZero const

[SimonSapin]

I came across this when experimenting with using intermediate const items to work around NonZero’s field being private and be able to use it in patterns.

Reduced test case:

#![feature(nonzero, const_fn)]
extern crate core;
use core::nonzero::NonZero;

fn main() {
    const FOO: NonZero<u64> = unsafe { NonZero::new(2) };
    if let FOO = FOO {}
}

Output with rustc 1.19.0-nightly (d3abc80 2017-05-09)

error[E0080]: constant evaluation error
   |
note: for pattern here
  --> a.rs:7:12
   |
7  |     if let FOO = FOO {}
   |            ^^^

error: aborting due to previous error

This error message is incomplete because of #41893, but hacking the compiler yields unimplemented constant expression: tuple struct constructors. That error message is emitted in src/librustc_const_eval/eval.rs.

It looks like non-tuple-like struct literals are handled in that file as the hir::ExprStruct(_, ref fields, _) variant, but tuple-like struct literals syntactically look like function calls so they end up in hir::ExprPath(ref qpath) then Def::StructCtor(_, CtorKind::Fn) instead, which is the unimplemented case. Beyond this I don’t really understand what’s going on.

CC @eddyb

[eddyb]

Yeah we can probably do it. Seems easier than bringing miri in which isn't happening as fast as I wanted to.

[eddyb]

On second thought, this is quite annoying because of the const fn call, which requires either duplicating const fn supporting in pattern expansion or driving the latter from const-eval which means expanding const-eval by quite a lot. I'd rather work on bringing miri in instead.

[SimonSapin]

As discussed on IRC, fixing this would probably enable using NonZero in string_cache::Atom. Which would be nice to have, but we’ve been living for years without it so far so I don’t mind waiting for miri :)