-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
ICE with unleash-miri: mutable allocation in constant #71316
Comments
Hm okay in another case it looks like we are actually expecting an ICE with miri-unleash? That seems rather extreme though. |
I thought that was the intent 😆 The miri-engine doesn't need to gracefully error in situations that can only occur in unleash mode. There's no way a user will ever see it unless we have a bug in either our knowledge of the engine or the static checks. |
That doesn't match what we do elsewhere though; CTFE doesn't ICE when it hits a This error is slightly different though... it is entirely unclear (to me at least) what the intended behavior is here. On the one hand the user asked for interior mutability, on the other hand it's a
|
Curiously, |
of these three options I'd choose the nice error. I'd rather bail out than introduce mutability to constants. |
I am getting the feeling that that check is overzealous... we also get an ICE for this constant, which arguably is fine: const MUTABLE_BEHIND_RAW: *const Vec<i32> = &Vec::<i32>::new() as *const _; |
In other words, the current const check in the |
In fact, this ICEs on stable: #![allow(const_err)]
const CONST_RAW: *const Vec<i32> = &Vec::new() as *const _;
fn main() {} |
This seems like one of the cases where we'd need to overwrite the mutability of the allocation. This is one of the promotion-without-promotable cases. The MIR is bb0: {
StorageLive(_1); // bb0[0]: scope 0 at src/main.rs:3:36: 3:59
StorageLive(_2); // bb0[1]: scope 0 at src/main.rs:3:36: 3:47
StorageLive(_3); // bb0[2]: scope 0 at src/main.rs:3:37: 3:47
_3 = const std::vec::Vec::<i32>::new() -> bb1; // bb0[3]: scope 0 at src/main.rs:3:37: 3:47
// ty::Const
// + ty: fn() -> std::vec::Vec<i32> {std::vec::Vec::<i32>::new}
// + val: Value(Scalar(<ZST>))
// mir::Constant
// + span: src/main.rs:3:37: 3:45
// + user_ty: UserType(0)
// + literal: Const { ty: fn() -> std::vec::Vec<i32> {std::vec::Vec::<i32>::new}, val: Value(Scalar(<ZST>)) }
}
bb1: {
_2 = &_3; // bb1[0]: scope 0 at src/main.rs:3:36: 3:47
_1 = &raw const (*_2); // bb1[1]: scope 0 at src/main.rs:3:36: 3:47
_0 = _1; // bb1[2]: scope 0 at src/main.rs:3:36: 3:59
StorageDead(_2); // bb1[3]: scope 0 at src/main.rs:3:58: 3:59
StorageDead(_1); // bb1[4]: scope 0 at src/main.rs:3:58: 3:59
return; // bb1[5]: scope 0 at src/main.rs:3:1: 3:60
} As you can see, there's no |
Yeah and interning already makes these immutable: rust/src/librustc_mir/interpret/intern.rs Line 386 in 08dfbfb
It just also ICEs currently, but that is fixed by #71665 (which makes it a hard error instead). |
Miri interning: replace ICEs by proper errors Fixes rust-lang#71316 I also did some refactoring, as I kept being confused by all the parameters to `intern_shallow`, some of which have invalid combinations (such as a mutable const). So instead `InternMode` now contains all the information that is needed and invalid combinations are ruled out by the type system. Also I removed interpreter errors from interning. We already ignored almost all errors, and the `ValidationFailure` errors that we handled separately actually cannot ever happen here. The only interpreter failure that was actually reachable was the UB on dangling pointers -- and arguably, a dangling raw pointer is not UB, so the error was not even correct. It's just that the rest of the compiler does not like "dangling" `AllocId`. It should be possible to review the 3 commits separately. r? @oli-obk Cc @rust-lang/wg-const-eval
Miri interning: replace ICEs by proper errors Fixes rust-lang#71316 I also did some refactoring, as I kept being confused by all the parameters to `intern_shallow`, some of which have invalid combinations (such as a mutable const). So instead `InternMode` now contains all the information that is needed and invalid combinations are ruled out by the type system. Also I removed interpreter errors from interning. We already ignored almost all errors, and the `ValidationFailure` errors that we handled separately actually cannot ever happen here. The only interpreter failure that was actually reachable was the UB on dangling pointers -- and arguably, a dangling raw pointer is not UB, so the error was not even correct. It's just that the rest of the compiler does not like "dangling" `AllocId`. It should be possible to review the 3 commits separately. r? @oli-obk Cc @rust-lang/wg-const-eval
I tried this code with
-Zunleash-the-miri-inside-of-you
:This is a variant of the
mutable_const
test.I am getting an ICE:
Cc @rust-lang/wg-const-eval
The text was updated successfully, but these errors were encountered: