Stream: wg-async-foundations

Topic: noalias / Stacked Borrows vs self-referential genreators


RalfJ (Aug 29 2019 at 20:42, on Zulip):

@Taylor Cramer after you left, @nikomatsakis and @centril and me talked some more, and the conclusion is that we can likely find some model that will make generators work. Given how desirable that use-case is, that seems like a constraint worth putting on the model, even if it complicates things. And given that we don't emit noalias for mutable reference ATM per default, it's also not super-urgent tog et this fixed because right now we are not misoptimizing anything (we generate UB-free LLVM IR, for all we know).
It is still a soundness bug though to generate UB-ful LLVM IR with -Zmutable-noalias. @nikomatsakis proposed fix is to search for generators inside mutable references (similar to how we search for UnsafeCell inside shard references), and inhibit the attribute when we find one.

Taylor Cramer (Aug 29 2019 at 20:47, on Zulip):

Is it enough to just turn of noalias on the references to generators while still having noalias on the references within the interior?

Taylor Cramer (Aug 29 2019 at 20:48, on Zulip):

I'd imagine that depends on whether you ever use the reference to the generator to derive a reference to the interior

Taylor Cramer (Aug 29 2019 at 20:48, on Zulip):

but I don't have a good sense for how the actual formal rules around noalias interact in this case

Taylor Cramer (Aug 29 2019 at 20:49, on Zulip):

(storing derived pointers)

RalfJ (Aug 29 2019 at 21:03, on Zulip):

storing a pointer has no effect on that pointer. it keeps its identity.

RalfJ (Aug 29 2019 at 21:03, on Zulip):

I'd imagine that depends on whether you ever use the reference to the generator to derive a reference to the interior

you are not allowed to derive a reference to the offending field (the one that has an outstanding loan)

Taylor Cramer (Aug 29 2019 at 22:42, on Zulip):

@RalfJ Yeah, so we can't ever debug print values that have existing mutable references to them

Taylor Cramer (Aug 29 2019 at 22:43, on Zulip):

which makes sense

RalfJ (Aug 30 2019 at 07:48, on Zulip):

which makes sense

glad that we agree on that :)

Vadim Petrochenkov (Aug 30 2019 at 10:03, on Zulip):

similar to how we search for UnsafeCell inside shard references

By the way, does this currently pessimize type-erased contexts where the type is hidden under dyn Trait or something like that?

Charles Lew (Aug 30 2019 at 17:33, on Zulip):

Hello, i was reading https://github.com/rust-lang/rust/issues/63818#issuecomment-526579977 . I think the direction is great, but the rules feels a little ad-hoc, and i feel if user defined something and its behavior is similar to generators, it won't be protected by the rule, if we only focus on the generator use case.

Charles Lew (Aug 30 2019 at 17:40, on Zulip):

I'm trying to make up my own theory, which might be similar but different in details.
I'm thinking about use a special named lifetime called 'self to mark the self-referential lifetime.

So for the original problem:

pub async fn test() -> i32 {
    let a: Cell<i32> = Cell::new(0);
    let mut b: &Cell<i32> = &a;
    SomeFuture.await;
    b.set(100);
    a.get()
}

I think it can desugar into

struct Test {
    state: ?,
    a: Cell<i32>,
    b: &'self Cell<i32>,
}

And when &'self is used in a struct S, it means it can be self-referential. And &mut S is no longer noalias.

Charles Lew (Aug 30 2019 at 17:44, on Zulip):

Maybe a more powerful version of borrowck in the future can build rules around this special lifetime, and reason about it.

Taylor Cramer (Aug 30 2019 at 20:02, on Zulip):

@Charles Lew lifetimes are erased, and cannot have different runtime behavior

RalfJ (Aug 31 2019 at 09:04, on Zulip):

similar to how we search for UnsafeCell inside shard references

By the way, does this currently pessimize type-erased contexts where the type is hidden under dyn Trait or something like that?

currently actually not, if you have an &dyn Trait Miri will figure out the "real" type and treat the reference accordingly. whether that is waht we want, I do not know.

Charles Lew (Aug 31 2019 at 14:31, on Zulip):

Charles Lew lifetimes are erased, and cannot have different runtime behavior

I thought named lifetimes can be a little special? But yes this system might be over-complex. I was just thinking about how to make the mechanism able to map to surface syntax.

Last update: Nov 18 2019 at 00:40UTC