Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Strange "Discriminant value outside specified type" with unsigned C-like enums #20600

Closed
Marwes opened this issue Jan 5, 2015 · 6 comments
Closed
Labels
A-typesystem Area: The type system

Comments

@Marwes
Copy link
Contributor

Marwes commented Jan 5, 2015

This code fails with a compile error when using the smaller unsigned types (u8, u16, u32) as a representation for the enum. For signed types or u64 the same code compiles fine so it seems there is some issue with truncation for unsigned types.

As a workaround it is possible to use an explicit cast (!0 as u8).

#[repr(u8)]
enum Test {
    A = 0,
    B = !0
}

fn main() {
}
error.rs:6:5: 6:11 error: discriminant value outside specified type [E0082]
error.rs:6     B = !0
               ^~~~~~
error.rs:3:8: 3:11 note: discriminant type specified here
error.rs:3 #[repr(u8)]
@Diggsey
Copy link
Contributor

Diggsey commented Jan 6, 2015

Strange, I thought it would be because it's "0" as opposed to "0u8" and so the compiler was inferring a larger integer type, but even with "!0u8" it still complains, even though typeof(!0u8) == u8, and "!0u8 as u8" works fine.

fn type_of<T>(_: &T) -> &'static str { unsafe { (*std::intrinsics::get_tydesc::<T>()).name } }

fn main() {
    let x = !0u8;
    println!("{}", type_of(&x));
}

@Marwes
Copy link
Contributor Author

Marwes commented Jan 8, 2015

I believe I figured out what is causing this behavior though I don't know how it should be fixed really.

The problem seems to come from the constant evaluator which only deals with 64-bit numbers. !0u8 is basically treated as !0u64 making a number that is to large when the bounds check is done. Might be that the constant evaluator need to take types into account.

@kmcallister kmcallister added the A-typesystem Area: The type system label Jan 11, 2015
@Marwes
Copy link
Contributor Author

Marwes commented Mar 8, 2015

Related #22531

@pnkfelix
Copy link
Member

cc #23897

@eefriedman
Copy link
Contributor

This is fixed in nightly.

@steveklabnik
Copy link
Member

Confirmed, thanks @eefriedman !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system
Projects
None yet
Development

No branches or pull requests

6 participants