fix various const eval errors

[oli-obk]

These were found after const_evaluating arbitrary expressions and linting if the const evaluator failed

fixes #33275 (int -> float casts for negative ints)
fixes #33291 (int -> char casts (new! wasn't allowed in constants until this PR))

r? @eddyb

cc @bluss @japaric

[eddyb]

This reminds me, we need 2 variants, one for f32 and one for f64.

[japaric]

hmm... where's bors? or is @japaric not a reviewer?

I have r+ rights, but I think I'm not be registered with the highfive bot.

fixes #33291 (int -> float casts for negative ints)
fixes #33275 (int -> char casts (new! wasn't allowed in constants until this PR))

the descriptions seem to be backward.

@oli-obk r=me with added tests cases 😄.

[oli-obk]

the descriptions seem to be backward.

whoops :) fixed

added tests cases

hmm... when I tried to create a cfail test for the error message I found out that it's the wrong message and the wrong logic. It's not possible to cast anything but a u8 to a char. And the regular rustc error message even says so. So I made sure that the value is either a u8 or at least can be inferred into a u8. But that caused some fallout in the infer function, because the cast-function doesn't have a span, but the infer function expects a span to report any errors. I changed this to only return an ErrKind and to attach the span in eval_const_expr_partial.

Note that typeck catches this issue, so we can only test for the const_eval error message by evaluating a pattern or array length

[japaric]

It's not possible to cast anything but a u8 to a char. And the regular rustc error message even says so.

Oh, right. I didn't remember that was the case.

Note that typeck catches this issue, so we can only test for the const_eval error message by evaluating a pattern or array length

So typeck doesn't reject this cast when it's in an array length. That's ... interesting.

[japaric]

Yay, more const casting possibilities.

[japaric]

@bors r+

Thanks @oli-obk!

[bors]

📌 Commit ce6ea47 has been approved by japaric

[durka]

another one: b"x" as &[u8]

[oli-obk]

@durka I can fix this easily. This is a mis-use of as, so we should probably start warning on it anyway

[durka]

How is it a misuse? It's unsizing the &[u8; 1] to a &[u8]. But more than that, the message is bad -- it says "cannot cast this type" while the code compiles, so it certainly does cast the type, and it doesn't give the user any information about why the cast might be invalid.

[oli-obk]

shouldn't a simple as_ref suffice?

#![feature(type_ascription)]

fn main() {
    let x = b"foo".as_ref();
    let y = x : &[u8];
}

I was under the impression that as should only be used for casting when there's no other way.

[eddyb]

@oli-obk Calling as_ref in non-generic code is an anti-pattern. Also, it doesn't matter if as is bad style, sometimes it's the simplest option (given that ascription doesn't coerce).
&b"foo"[..] works but it's a bit uglier.
The problem is that the warning is wrong: the coercion/cast works fine, even if it's not implemented in const_eval.