Skip to content

non-exhaustive match failure in eval_const_expr when shift arguments differ in signedness #2426

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
msullivan opened this issue May 22, 2012 · 2 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@msullivan
Copy link
Contributor

eval_const_expr always requires the arguments of a binary op to have the same type, which needn't be true for shift operators. Forcing eval_const_expr to be called on such a shift triggers a compiler failure.

enum bs { thing = 5 >> 1u }
fn main() {
    log(error, thing as int);
}
@eholk
Copy link
Contributor

eholk commented May 22, 2012

If anything, should the right hand side of the shift operator be unsigned?

@msullivan
Copy link
Contributor Author

rust allows any integral type as the rhs of shifts.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
Use real exec on cfg(unix) targets

Closes rust-lang/miri#2421

The standard library has a platform extension trait that lets us get the behavior we want on cfg(unix), so why not use it?

I tried this out and it produces the correct behavior in concert with nextest.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

No branches or pull requests

2 participants