const-eval: explain the final-value-byte-provenance restriction

[RalfJung]

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.

[traviscross]

Suggested change

	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.)

[RalfJung]

The lines aren't wrapped...?

[traviscross]

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.

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.