Fix copy_from_slice

[nitnelave]

There is no guarantee that the slices are not overlapping.

This was discovered due to #58783

[rust-highfive]

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

[nitnelave]

r? @RalfJung

[nitnelave]

I'd like to add a test, but I'm not sure where.

[RalfJung]

A shared slice may never overlap with a mutably borrowed one. So this change does not seem right to me.

[nitnelave]

Sorry, I may have gone a bit fast, my train was about to leave. If the caller is unsafe, it's possible, no? But in that case, who bears the responsibility? In our case, the caller was vector.clone(), if I remember correctly. In that case, if I can read the code correctly, it means that src is the previous vector, and dst is the one we're creating. It seems weird that the two overlap. Maybe the assertion is badly written, but I just reviewed it and it doesn't seem wrong, or overly strict.

…

On Thu, Feb 28, 2019, 16:02 Ralf Jung ***@***.***> wrote: A shared slice may never overlap with a mutably borrowed one. So this change does not seem right to me. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#58810 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwn2SpiE8pj1bZXkbneiS40bE6M3j5gks5vR-9zgaJpZM4bW_me> . On Thu, Feb 28, 2019, 16:02 Ralf Jung ***@***.***> wrote: A shared slice may never overlap with a mutably borrowed one. So this change does not seem right to me. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#58810 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwn2SpiE8pj1bZXkbneiS40bE6M3j5gks5vR-9zgaJpZM4bW_me> .

[RalfJung]

If the caller is unsafe, it's possible, no? But in that case, who bears the responsibility?

The caller. You must not create such overlapping references, period -- even if you don't use them, that's already UB.

[Dylan-DPC-zz]

ping from triage @nitnelave @RalfJung any updates on this?

[nitnelave]

Sorry, I need to debug this, but it's trickier than expected (and I didn't have time recently). I'll try to have another swing at it some time this week.

[Dylan-DPC-zz]

sure @nitnelave no issues :)

[RalfJung]

I think this PR should be closed. The change is incorrect (or rather, unnecessary: we may assume here that the slices don't alias, and there is nothing gained by using copy instead of copy_nonoverlapping). Further investigation is needed in #58783 to determine what causes the assertion failure.

[nitnelave]

fair enough, I'll open a new one when I have a better fix :)