Qualify constness in rvalue expressions for promotion to globals. #21744
Conversation
|
r? @nick29581 (rust_highfive has picked a reviewer for you, use r? to override) |
|
⌛ Testing commit acb37ce with merge f3f47ad... |
|
💔 Test failed - auto-win-32-nopt-t |
eddyb
force-pushed
the
rvalue-promotion
branch
from
acb37ce
to
91d51c8
Compare
|
@bors try 91d51c8 |
|
⌛ Testing commit 91d51c8 with merge c41f7b6... |
|
💔 Test failed - auto-mac-64-opt |
eddyb
force-pushed
the
rvalue-promotion
branch
from
91d51c8
to
f9556d8
Compare
|
@bors try f9556d8 |
|
⌛ Testing commit f9556d8 with merge 70b6649... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
This looks great: r+ I have some nits and minor comments, which you can find as comments in this commit: nikomatsakis@feb8ca7 |
|
Blocked on #21996. |
eddyb
force-pushed
the
rvalue-promotion
branch
from
f9556d8
to
a091c5a
Compare
|
@bors r=nikomatsakis a091c5a |
|
⌛ Testing commit a091c5a with merge 5fcfa12... |
|
💔 Test failed - auto-mac-32-opt |
|
💔 Test failed - auto-linux-64-nopt-t |
…ypes with [u8; 0].
eddyb
force-pushed
the
rvalue-promotion
branch
from
7e45074
to
b49f528
Compare
This includes everything necessary for promoting borrows of constant rvalues to `'static`. That is, `&expr` will have the type `&'static T` if `const T: &'static T = &expr;` is valid. There is a small exception, dereferences of raw pointers, as they misbehave. They still "work" in constants as I didn't want to break legitimate uses (are there any?). The qualification done here can be expanded to allow simple CTFE via `const fn`.
|
Isn't this designed to make |
|
Epic fight with @bors! |
|
(If tests are added, they can close rust-lang/rfcs#827.) |
|
@huonw No, that part needs an RFC. @nikomatsakis wanted to write one for the longest time - in any case, there's a few different directions to go from this base implementation. |
Do not promote &mut of a non-ZST ever
Since ~pre-1.0~ 1.36, we have accepted code like this:
```rust
static mut TEST: &'static mut [i32] = {
let x = &mut [1,2,3];
x
};
```
I tracked it back to rust-lang#21744, but unfortunately could not find any discussion or RFC that would explain why we thought this was a good idea. And it's not, it breaks all sorts of things -- see rust-lang#75556.
To fix rust-lang#75556, we have to stop promoting non-ZST mutable references no matter the context, which is what this PR does. It's a breaking change.
Notice that this still works, since it does not rely on promotion:
```rust
static mut TEST: &'static mut [i32] = &mut [0,1,2];
```
Cc @rust-lang/wg-const-eval
Do not promote &mut of a non-ZST ever
Since ~pre-1.0~ 1.36, we have accepted code like this:
```rust
static mut TEST: &'static mut [i32] = {
let x = &mut [1,2,3];
x
};
```
I tracked it back to rust-lang#21744, but unfortunately could not find any discussion or RFC that would explain why we thought this was a good idea. And it's not, it breaks all sorts of things -- see rust-lang#75556.
To fix rust-lang#75556, we have to stop promoting non-ZST mutable references no matter the context, which is what this PR does. It's a breaking change.
Notice that this still works, since it does not rely on promotion:
```rust
static mut TEST: &'static mut [i32] = &mut [0,1,2];
```
Cc `@rust-lang/wg-const-eval`
This includes everything necessary for promoting borrows of constant rvalues to
'static.That is,
&exprwill have the type&'static Tifconst T: &'static T = &expr;is valid.There is a small exception, dereferences of raw pointers, as they misbehave.
They still "work" in constants as I didn't want to break legitimate uses (are there any?).
The qualification done here can be expanded to allow simple CTFE via
const fn.