Errors in constants and promoteds stop compilation (via deny-by-default lint) even in dead code

[lcnr]

example by @felix91gr

#![feature(const_generics)]
#![allow(const_err)]

fn foo<const C: u8>() {
  if C > 0 {
    println!("Foo gives {}", 25 / C);
  }
  else {
    println!("Foo gives 0");
  }
}

fn main() {
  foo::<0>();
}

Note that this currently requires allow(const_err) because 25 /C would panic at runtime.
This is however fine as it isn't reachable because of C > 0.

We probably should relax this slightly here, not sure what's the best approach though

Other example (by @RalfJung)

const D: u8 = 0; // imagine this is in a different crate

pub fn foo() {
    if D > 0 {
        let _val = 25/D; // ERROR
    } else {
        panic!()
    }
}

[felix91gr]

For what it's worth: it works fine for me in a nightly playground. I'm assuming the current const_err feature is not in nightly yet, right? @lcnr, and that's why it currently builds?

Edit for future people: see the two answers below :)

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=2c1e04dc98cd3d125da836c4b1d5b147

[lcnr]

It works because I added #![allow(const_err)]. Remove that line and you get an error

[felix91gr]

AHH, I thought that flag was to enable the const_err checking 😄

Here's the playground then, with the error enabled :3 https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=28ae219a9e7d1054cb7009c5bb254686

[RalfJung]

Hm, this is interesting. It feels loosely related to discussions we recently had about constants always having to be well-formed even when unused (Cc #67191).

But this time, it also involves promotion -- at least, I think 25/C is being promoted (println! adds an implicit &). Promotion should not lead to hard errors though, so something is odd.

Cc @oli-obk

[oli-obk]

There's no hard error involved, so all is fine from that perspective. I guess we'll need some sort of control flow based const prop to not hit these cases

[RalfJung]

Promoteds don't usually trigger const_err though. Some logic somewhere doesn't seem right here.

Remember that const_err is slated to become a hard error.

[oli-obk]

oh... I guess we should just not propagate const generics at all. We can't enfore wf bounds for promoteds, because they are implicitly generated. This is the same issue we have with associated constants:

This happens on stable: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c5377d51d296c31a0cb1284269833bf5

[RalfJung]

I don't see why we wouldn't const-prop them. We just have make the lint less silly.

This doesn't look like a const-prop thing at all to me. Const-prop doesn't emit const_err, or at least it shouldn't. The following would be expected to error:

if ... {
  const FOO: i32 = something / 0;
  FOO
} else { ... }

The bug is that here we get this error not for a const but for a promoted -- unlike consts, those do not have to evaluate successfully.

I wonder how anon-const-blocks should behave here... Cc rust-lang/rfcs#2920 @ecstatic-morse

[oli-obk]

Ugh. Why are words so similar and why do I keep mixing them up.

I think we should not promote const generics at all. Const prop is entirely irrelevant here.

EDIT: we could promote direct uses of const generics (so let x = &N;) or once we have wf bounds for const expressions, we can promote anything which has a wf bound.

[felix91gr]

What is promoting, in this context? Sorry I have to ask, but this topic is very interesting to me and I can't follow what you guys are saying x3

[oli-obk]

Promotion is the action of implicitly generating constants even if the user did not explicitly write anything to that regard. Further reading is available in the reference: https://doc.rust-lang.org/stable/reference/destructors.html?highlight=promotion#constant-promotion

[felix91gr]

Ahh I see. So like, say we have a constant and we use it like this:

const SIZE : u32 = 10;

fn foo() -> {

  let a = [0; SIZE]; // maybe I wrote it wrong, but the idea is that a is an array of 0s of length SIZE.

  println!("{}", a);
}

Then a could be promoted to a constant by the compiler because it can prove that it can do so without problems. Right?

And then, after promotion, a is treated like a constant for all intents and purposes for the remainder of the compilation process.