Code change:
No matter what kind of const eval features we add, we should never allow this. Even if we managed to allow this, I think the current impl would ICE. Even if it does not ICE, it could never actually modify the memory. We should ensure that the following code always errors.
Hi , I would like to work on this if that's ok. I'm a new Rustacean and I'm learning rustc development and testing. It's time to get my feet wet
Great! I think the following steps should suffice, but don't hesitate to ask if anything is unclear or doesn't work as expected the test in a new file in a annotation to the line that should report an error (replace "error message here" with the relevant error message) 3 until everything is green your test and the generated file and open a PR to the PR message so when it gets merged this issue gets closed automatically
Hi , When I was running the test in step 3, or compiled the new test with nightly rustc (rust-lang/rust I got errors like this. error[E0015]: calls in statics are limited to constant functions, tuple structs and tuple variants --mod-static-with-const- | 24 | () = 5; | ^^^^^^^^^^^ error[E0658]: statements in statics are unstable (see issue ) --mod-static-with-const- | 24 | () = 5; | ^^^^^^^^^^^^^^^^ | = help: add #![feature(constlet)] to the crate attributes to enable error: aborting due to 2 previous errors I think E0015 is the expected error. But I'm not sure about E0658. It seems that the constlet feature is not stabilized yet. (But compiling doesn't return this error.) Could you please help with this problem? Thanks a lot.
These errors are fine. the idea of this issue is to just make sure the code always fails to compile. More errors are fine, too. the const let feature has a bug where even enabling it will still report it. that's not problematic for this issue. Can you add a comment to the test mentioning that this test should never ever succeed? If you want you can additionally try to minimize the test to something still emitting the feature gate error even though the feature gate is active (and maybe to something that should be perfectly fine at compile time). then open a new issue about that.
Thanks ! I will try to reproduce the unexpected error related to the feature gate. Meanwhile it seems that this task will be blocked by that issue since the ui test will fail if the error signature doesn't match with the expected one. Is that right?
you can just make them match ;) Add all the annotations you need to make the test pass. Whenever someone changes your test, because they fixed other bugs or implemented new features, they'll hopefully look at the comment about the fact that the test should never succeed to compile.

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // New test for #53818: modifying static memory at compile-time is not allowed. // The test should never succeed. #![feature(const_raw_ptr_deref)] #![feature(const_let)] use std::cell::UnsafeCell; struct Foo(UnsafeCell<u32>); unsafe impl Send for Foo {} unsafe impl Sync for Foo {} static FOO: Foo = Foo(UnsafeCell::new(42)); static BAR: () = unsafe { *FOO.0.get() = 5; //~^ ERROR calls in statics are limited to constant functions, tuple structs and tuple variants // This error is caused by a separate bug that the feature gate error is reported // even though the feature gate "const_let" is active. //~| statements in statics are unstable (see issue #48821) }; fn main() { println!("{}", unsafe { *FOO.0.get() }); } </ins>