allow constants to refer to mutable/external memory, but reject such constants as patterns #1859
Conversation
…constants as patterns
|
I'm trying to figure out, which reference rule rejects the following? static mut S: i32 = 1;
const C: &mut i32 = unsafe { &mut S }; // ERROR: constructing invalid valueWhat I'm getting at, is that it seems like despite removing
Is there maybe still some "final value must not have mutable references" restriction? Is there some rule in the reference that would explain the following? const C: &AtomicU32 = &AtomicU32::new(1); // ERROR: constants cannot refer to interior mutable dataIt seems like a pretty strong blanket statement that "constants cannot refer to interior mutable data", but the AtomicU32 example from rust-lang/rust#140942 seems like you can refer to interior mutable data. What exactly is the difference between a reference to a static versus a reference to a value created in the initializer? Similarly, I'm trying to understand E0764. Is the description of E0764 out of date? const C: &mut i32 = &mut 1; // ERROR: mutable references are not allowed in the final value of constantsQuestions:
|
|
So, I can't always tell you where any of that is in the reference, I had a hard time even find the things I am editing here.^^ But I can tell you what the compiler does: static mut S: i32 = 1;
const C: &mut i32 = unsafe { &mut S }; // ERROR: constructing invalid valueWe do a type-directed pass over the final value of the constant, mostly to check e.g. that every
const C: &AtomicU32 = &AtomicU32::new(1); // ERROR: constants cannot refer to interior mutable dataThat falls out of the following two things which are in the reference:
Oh yeah, that is very outdated. And I don't understand that "remember" thing either. (I worry this might be true for many of our error descriptions -- at least I don't ever seem them so I wouldn't even notice them being outdated. Multiple of our Exxxx tests don't even emit the right error code any more...) const C: &mut i32 = &mut 1; // ERROR: mutable references are not allowed in the final value of constantsThis is the exact same as "constants cannot refer to interior mutable data", but for a mutable reference rather than an interior mutable shared ref. I don't know why the error messages are worded so differently... |
|
@RalfJung we had some discussion in the spec about this wording. I'm having a hard time (quite honestly) knowing with precision what you are saying and what the spec is saying. I want to present my mental model and check if it works for you and then ask you some questions in terms of that model. CONST VALUEA const "value" is defined by some kind of grammar that looks kind of like a valtree (but with some extra things):
where a referent is either a static value (in which case we know which static) or another valtree (indicating a constant). And then when you say, "we do a type-directed pass over the final value of the constant", I take it that you have a pair like (Type, Value) and then we can kind of "visit" the components in a relatively straightforward way. And then when you say, "we just throw an error if we find any mutable reference in a const", you mean that if at any point in this traversal, Does that all make sense to you? Is my model accurate? If it would be helpful I can try to write it in a kind of pseudo-code-y Rust. |
| r[items.const.final-value-immutable] | ||
| The final value of a `const` item cannot contain references to anything mutable. | ||
|
|
There was a problem hiding this comment.
We were wondering if it would make sense to change the wording here instead of removing it. Perhaps something like:
"The final value of a const item cannot contain a mutable reference."
Most of us seemed to think this is correct. Perhaps there is some other rule forbidding this already (implicitly or explicitly), but it seems like it wouldn't hurt to be clear about it here?
|
No, it's not a valtree. Speaking about the internal compiler representation, a But given an arbitrary place and a type, we can just walk that place according to the type. We don't construct a tree, we just do a type-guided traversal of this memory, recursing into structs and tuples and enums and so on. That's what const validation does. Mostly that traversal just checks regular (recursive) validity, but for mutability we are super extra paranoid to make it less likely for (I will note that we are now digging into pre-existing lacks of documentation here, and have ventured far outside of what rust-lang/rust#140942 is about. I'd rather not have to rebase that PR again while we figure out how to document things that have been undocumented for years...) |
Reference update for rust-lang/rust#140942.