Stream: general

Topic: miri trying to reborrow for Unique


Elichai Turkel (Nov 21 2019 at 09:15, on Zulip):

Hi, I'm testing this library: https://github.com/Michael-F-Bryan/const-arrayvec
I'm getting a miri error but i'm not quite sure if it's a false positive or is the code unsound:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=bb0b383aca6792aa7e1dc96a9979ffa3
@RalfJ @oli

oli (Nov 21 2019 at 09:18, on Zulip):

I'm not sure, but https://github.com/Michael-F-Bryan/const-arrayvec/blob/147553ca706176fe5cf1d56b2334a198bfba197a/src/lib.rs#L188 may be nuking the borrow stack for tail

Elichai Turkel (Nov 21 2019 at 09:22, on Zulip):

@oli I tried switching places between the tail and set_len and it didn't help.

oli (Nov 21 2019 at 09:23, on Zulip):

hmm

Elichai Turkel (Nov 21 2019 at 09:23, on Zulip):

Ha. moving self.set_len(new_length); to the end of the function resolves this error.
Is this somehow unsoundness? (i.e. should be fixed) or is this miri not being able to determine that the borrow has ended?

oli (Nov 21 2019 at 09:23, on Zulip):

yea

oli (Nov 21 2019 at 09:23, on Zulip):

that is unsound

oli (Nov 21 2019 at 09:23, on Zulip):

^^

oli (Nov 21 2019 at 09:24, on Zulip):

the placement is very much on purpose

oli (Nov 21 2019 at 09:24, on Zulip):

you can inline the body of set_len

oli (Nov 21 2019 at 09:24, on Zulip):

if you set it at the end, if dropping elements panics, you still have access to the elements that were dropped but didn't panic

Elichai Turkel (Nov 21 2019 at 09:24, on Zulip):

Meaning that the change to len needs to be only after dropping?

oli (Nov 21 2019 at 09:25, on Zulip):

If you want to know more about this google "pre-pooping your pants rust drop"

oli (Nov 21 2019 at 09:25, on Zulip):

very amusing blog post

Elichai Turkel (Nov 21 2019 at 09:25, on Zulip):

oh so you're saying the opposite? that if I resolve miri's error by setting the len only afterwards this introduces unsoundness? hmm

Elichai Turkel (Nov 21 2019 at 09:25, on Zulip):

will do :)

Elichai Turkel (Nov 21 2019 at 09:25, on Zulip):

oh that's related to @gnzlbg PR to Vec

Elichai Turkel (Nov 21 2019 at 09:26, on Zulip):

https://github.com/rust-lang/rust/pull/64432

Elichai Turkel (Nov 21 2019 at 09:28, on Zulip):

so inlining set_len works too. I don't understand

gnzlbg (Nov 21 2019 at 09:44, on Zulip):

Like Oli said, read “pre-pooping your pants”

gnzlbg (Nov 21 2019 at 09:45, on Zulip):

I wonder what people reading Rust threads about pooping pants think about us, but that has become the technical term :laughter_tears:

RalfJ (Nov 21 2019 at 10:29, on Zulip):

@Elichai Turkel lol I think you replicated https://github.com/bluss/arrayvec/pull/144

Elichai Turkel (Nov 21 2019 at 10:44, on Zulip):

@RalfJ lol, i'll also PR the changes after I finish reading the blog post (and actually understand why calling a function with &mut self is inherently different than inlining it :P )

RalfJ (Nov 22 2019 at 14:01, on Zulip):

the problem with the &mut self function is mutable reference

RalfJ (Nov 22 2019 at 14:01, on Zulip):

a function fn foo(x: &mut T) must be able to rely on x being the only pointer to this instance of T

RalfJ (Nov 22 2019 at 14:02, on Zulip):

so if there are aliases that were created before (such as raw ptrs) and used later, that's illegal -- it makes x not the only live pointer

Elichai Turkel (Nov 23 2019 at 19:50, on Zulip):

@RalfJ I was about to write "isn't that an inefficiency of the borrow checker? " but then I realized this can definitely be unsound:

fn main() {
    let mut a = vec![20, 20, 20];
    dbg!(a.capacity());
    let a_slice = unsafe { std::slice::from_raw_parts(a.as_ptr(), a.len()) };
    a.extend_from_slice(&[64u8; 64]);
    dbg!(a.capacity());
    dbg!(a_slice);
}
Elichai Turkel (Nov 23 2019 at 19:51, on Zulip):

and I finished pre pooping my pants :)

RalfJ (Nov 25 2019 at 13:07, on Zulip):

that code actually writes to a though (inside extend_from_slice), it doesnt just create a mutable ref

Last update: Dec 12 2019 at 00:45UTC