Auto merge of #30587 - oli-obk:eager_const_eval2, r=nikomatsakis
typestrong const integers ~~It would be great if someone could run crater on this PR, as this has a high danger of breaking valid code~~ Crater ran. Good to go. ---- So this PR does a few things: 1. ~~const eval array values when const evaluating an array expression~~ 2. ~~const eval repeat value when const evaluating a repeat expression~~ 3. ~~const eval all struct and tuple fields when evaluating a struct/tuple expression~~ 4. remove the `ConstVal::Int` and `ConstVal::Uint` variants and replace them with a single enum (`ConstInt`) which has variants for all integral types * `usize`/`isize` are also enums with variants for 32 and 64 bit. At creation and various usage steps there are assertions in place checking if the target bitwidth matches with the chosen enum variant 5. enum discriminants (`ty::Disr`) are now `ConstInt` 6. trans has its own `Disr` type now (newtype around `u64`) This obviously can't be done without breaking changes (the ones that are noticable in stable) We could probably write lints that find those situations and error on it for a cycle or two. But then again, those situations are rare and really bugs imo anyway: ```rust let v10 = 10 as i8; let v4 = 4 as isize; assert_eq!(v10 << v4 as usize, 160 as i8); ``` stops compiling because 160 is not a valid i8 ```rust struct S<T, S> { a: T, b: u8, c: S } let s = S { a: 0xff_ff_ff_ffu32, b: 1, c: 0xaa_aa_aa_aa as i32 }; ``` stops compiling because `0xaa_aa_aa_aa` is not a valid i32 ---- cc @EddyB @pnkfelix related: https://github.com/rust-lang/rfcs/issues/1071
Showing
src/librustc_const_eval/err.rs
0 → 100644
src/librustc_const_eval/int.rs
0 → 100644
此差异已折叠。
src/librustc_const_eval/is.rs
0 → 100644
src/librustc_const_eval/lib.rs
0 → 100644
src/librustc_const_eval/us.rs
0 → 100644
src/test/run-pass/issue-23833.rs
0 → 100644
想要评论请 注册 或 登录