Stream: t-lang/wg-unsafe-code-guidelines

Topic: Fixing VecDeque for stricter Stacked Borrows


RalfJ (Nov 29 2018 at 17:07, on Zulip):

@nikomatsakis any opinion on https://github.com/rust-lang/rust/pull/56161 ?

nikomatsakis (Nov 30 2018 at 23:01, on Zulip):

@RalfJ on which aspect of it exactly? on the final changes that wound up being needed?

RalfJ (Dec 01 2018 at 08:15, on Zulip):

yeah, basically. does that seem like a reasonable change to request (and make the original code UB, long-term)? can we land this change?

Gankro (Dec 04 2018 at 15:43, on Zulip):

I am still curious if there's any footing in being able to declare an as/coercion chain in a single expr as "atomic" in the sense that only the start and end matter (which would fix this, yes?)

Nicole Mazzuca (Dec 04 2018 at 17:02, on Zulip):

@Gankro I feel like my personal favorite solution is "the point at which the reference becomes an object"

Nicole Mazzuca (Dec 04 2018 at 17:02, on Zulip):

while it's still a value, it can be invalid

Gankro (Dec 04 2018 at 17:02, on Zulip):

i have no idea what object means in this context

Nicole Mazzuca (Dec 04 2018 at 17:02, on Zulip):

like, when it gets bound to a name

Nicole Mazzuca (Dec 04 2018 at 17:03, on Zulip):

(although it should also apply in return context)

Nicole Mazzuca (Dec 04 2018 at 17:04, on Zulip):

i.e., let x = &<invalid-lvalue>; <- not valid, let x = &<invalid-lvalue> as &T as &T as *const T; <- fine

Gankro (Dec 04 2018 at 17:06, on Zulip):

Did y'all ever go forward with being able to pass things by-value where references are expected?

Gankro (Dec 04 2018 at 17:06, on Zulip):

(maybe causes problems with this kind of logic)

rkruppe (Dec 04 2018 at 17:08, on Zulip):

Likely too risky wrt breaking code expecting some address stability, but passing by value would also "create an object" in this terminology

rkruppe (Dec 04 2018 at 17:10, on Zulip):

er, phrased like that it's the wrong way around for what you're saying, but the other way around (when the source code passes a reference) is fine too

gnzlbg (Dec 07 2018 at 09:27, on Zulip):

@RalfJ why are the as *[const,mut] T required ?

gnzlbg (Dec 07 2018 at 09:33, on Zulip):

Shouldn't NonZero(reference) just work ?

RalfJ (Dec 07 2018 at 10:19, on Zulip):

i.e., let x = &<invalid-lvalue>; <- not valid, let x = &<invalid-lvalue> as &T as &T as *const T; <- fine

IMO that's way too non-compositional. We should be able to describe behavior as a sequence of steps in a simple language (on the level of MIR, but not quite MIR). Seen from that lense, what you are saying sounds a bit like my Raw Reference RFC, but with more cases being translated to "the raw ref operation"?
Crucially, I think we want a syntactic condition here, not something semantic/operational like "bound to a name".

RalfJ (Dec 07 2018 at 10:19, on Zulip):

Shouldn't NonZero(reference) just work ?

hm. maybe? the code had casts in it from the start

RalfJ (Dec 07 2018 at 10:21, on Zulip):

@gnzlbg yeah it works but it also desugars to first creating a raw ref and then casting that to *const :(

gnzlbg (Dec 07 2018 at 10:25, on Zulip):

so what's the point of the as _ ?

gnzlbg (Dec 07 2018 at 10:25, on Zulip):

maybe the code was trying to properly cast to a *const T but failed

RalfJ (Dec 07 2018 at 10:30, on Zulip):

so what's the point of the as _ ?

beats me

Last update: Nov 19 2019 at 18:10UTC