Fix assembling mutable slice from const reference #1358
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The pointer from which a mutable reference is created must have
provenance for accessing the underlying elements of the struct and its
fields (a single array here) mutably. A pointer acquired by
slice::as_ptr does not have that provenance, it only allows shared read
access. The
slice::as_ptr
method says:This fails MIRI which checks for this assertion but I'm not aware of
mis-compilation resulting from it. In fact, consider:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=28d3c19800236ae520441a22a6f99b19
Then llvm-IR in optimization will show that the functions are collapsed
to a single one, hinting there is no semantic difference at that level.
The difference in codegen is a readonly attribute on the slice::as_ptr
argument but this is scoped to the particular function and argument, not
the pointer value itself:
Since the outer function correctly takes a
&mut self
argument therestriction possibly no longer applies to our own method. Of course, a
stricter codegen of Rust's memory model might not be as kind and exploit
the MIR level UB here.