const-eval: explain the final-value-byte-provenance restriction #2138
Conversation
rustbot
added
the
S-waiting-on-review
src/const_eval.md
Outdated
| if a byte has provenance but is not part of an adjacent group of bytes that form an entire pointer, compilation will fail. | ||
|
|
||
| If a byte in the representation of the final value is uninitialized, then it *may* end up having provenance, which can cause compilation to fail. | ||
| As a quality-of-implementation concern, the compiler should only actually fail if the initializer copied or overwrite parts of a pointer and that memory ends up in the final value. |
There was a problem hiding this comment.
| As a quality-of-implementation concern, the compiler should only actually fail if the initializer copied or overwrite parts of a pointer and that memory ends up in the final value. | |
| As a quality-of-implementation concern, the compiler should only actually fail if the initializer copies or overwrites parts of a pointer and that memory ends up in the final value. |
(And we'll want to unwrap the lines.)
There was a problem hiding this comment.
The lines aren't wrapped...?
There was a problem hiding this comment.
We'll remove the line break between lines 239 and 240 and between 236 and 237.
There was a problem hiding this comment.
Oh, you don't want to break for colons? Okay, sure.
Good question. We had put the restrictions on the final value of a const in the chapter on const items, but given that this applies to static items as well that'd be maybe a bit more annoying. Maybe @ehuss will have a good idea on this. |
traviscross
added
the
I-lang-docs-nominated
RalfJung
force-pushed
the
const-eval-final-value-byte-provenance
branch
2 times, most recently
from
5b019ef to
76556a2
Compare
The text here is describing a restriction on the final value of a constant or static initializer. We could put this in the chapters for constant and static items, but then we'd have to duplicate it. At the same time, it doesn't make sense to be in the section for constant expressions since this is not a restriction on those expressions. Let's solve this, for now, by keeping it in the chapter on constant evaluation but putting it in a new "constant initializers" section. We'll move the second paragraph, which states what a compiler should do as a "quality-of-implementation" matter, into an admonition, and we'll reword this a bit to talk about what `rustc` does (but does not guarantee) to match the style we use for this in other places. We also add links to the appropriate chapters and sections for constant and static initializers.
traviscross
force-pushed
the
const-eval-final-value-byte-provenance
branch
from
76556a2 to
a5410c9
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
ehuss
removed
the
I-lang-docs-nominated
4 participants
This is the docs part for rust-lang/rust#148967.
I had no idea where to put it. Putting it in "const-expr" is odd since that is generally a compositional notion (the subexpressions of a const expression must be const expressions), whereas the limitation I am describing here only applies at the top level, i.e. for the final value of a const/static initializer.