Diagnostic: "constant evaluation error" without further details

[SimonSapin]

#![feature(nonzero, const_fn)]

extern crate core;

mod a {
    use core::nonzero::NonZero;

    #[derive(Eq, PartialEq)]
    pub struct Foo {
        bar: NonZero<u64>,  // Private
    }

    pub const FOO: Foo = Foo {
        bar: unsafe { NonZero::new(2) },
    };
}

fn main() {
    assert!(a::FOO == a::FOO);
    assert!(match a::FOO {
        a::FOO => true,
        _ => false,
    });
}

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

error[E0080]: constant evaluation error
   |
note: for pattern here
  --> a.rs:21:9
   |
21 |         a::FOO => true,
   |         ^^^^^^

error: aborting due to previous error

The error message doesn’t say what’s wrong with this pattern. Based on code in src/librustc/middle/const_val.rs it looks like more info should be printed, with ConstEvalErr::description.

CC @eddyb

[SimonSapin]

I was able to learn more with:

diff --git a/src/librustc/middle/const_val.rs b/src/librustc/middle/const_val.rs
index 3bbaf5c929..7e98f25894 100644
--- a/src/librustc/middle/const_val.rs
+++ b/src/librustc/middle/const_val.rs
@@ -205,6 +205,7 @@ impl<'a, 'gcx, 'tcx> ConstEvalErr<'tcx> {
             diag.span_note(primary_span,
                         &format!("for {} here", primary_kind));
         }
+        panic!("{:?}", self.description());
     }
 
     pub fn report(&self,

thread 'rustc' panicked at 'Simple("unimplemented constant expression: tuple struct constructors")', src/librustc/middle/const_val.rs:208

Let’s keep this issue about the error description not being shown. I’ll file a separate issue about the unimplemented bit.

Smaller test case with same results:

#![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 {}
}

[oli-obk]

It's not related to const eval apparently, because

fn main() {
    const I: usize = 0 - 1;
    if let I = 42 {}
}

produces

error[E0080]: constant evaluation error
 --> <anon>:7:22
  |
7 |     const I: usize = 0 - 1;
  |                      ^^^^^ attempt to subtract with overflow
  |
note: for pattern here
 --> <anon>:8:12
  |
8 |     if let I = 42 {}
  |   

as expected. I assume it has something to do with the emitter itself.

Playpen: https://is.gd/RrPhcP

[Mark-Simulacrum]

The span issue has been fixed -- closing.

error[E0080]: constant evaluation error
  --> /home/mark/BuildDisk/rust/src/libcore/nonzero.rs:47:9
   |
47 |         NonZero(inner)
   |         ^^^^^^^ unimplemented constant expression: tuple struct constructors
   |
note: for pattern here
  --> test.rs:21:9
   |
21 |         a::FOO => true,
   |         ^^^^^^

error: aborting due to previous error(s)

[SimonSapin]

@Mark-Simulacrum What test case is this? On both test cases in this issue I still get “constant evaluation error” “for pattern here” without further details, on rustc 1.20.0-nightly (69c65d2 2017-06-28).

I think this should be re-opened.

[SimonSapin]

Oh, I see that this the first test case, and the first line of code in the error message is from libcore. It also looks like you built this compiler yourself. Is the fix maybe on in Nightly yet? Or does the first part of the error message only show up when libcore sources are available at the same path they were compiled?

[eddyb]

@SimonSapin Have you tried installing the rust-src component in rustup?

[SimonSapin]

info: component 'rust-src' is up to date

It probably ends up at a different path than on the build servers, though? Does rustc know where to find it?

[SimonSapin]

FWIW, I have a non-default $RUSTUP_HOME environment variable set.

[SimonSapin]

Regardless, I think it’s a bug to skip half of the error message with relevant info when the corresponding source is not available to show context.

[Mark-Simulacrum]

It might be a bug in rustc/rustup interaction; I'll reopen for now. I test with a locally compiled rustc.

[SimonSapin]

Ok, so I’m convinced this is two issues:

• rustc doesn’t know where to find the rust-src component from rustup. Perhaps a new environment variable would help?
• When some sources are not available (which can happen for a variety of reasons), the error message omits valuable information that it would have printed in context next to a relevant source line. It should fall back to not printing the source context but still provide the information.

[eddyb]

@SimonSapin Ah that second one is the result of the new label system... I find it a bit problematic in general, given the fact that we still have the "error headers" - we should only have one system IMO, and it should look like the current "error headers" with no source code (but still show the path, line & column for manual lookup).

As for finding rust-src... I guess that's tricky and rustup would have to provide a path somehow - while distros would probably hardcode their source directory in the compiler.

cc @rust-lang/dev-tools