Mutable references vs self-referential structs #148

RalfJung · 2019-06-21T19:45:30Z

Turns out that stacked borrows and self-referential generators don't go well together. This code fails in Miri:

#![feature(generators, generator_trait)]

use std::{
    ops::{Generator, GeneratorState},
    pin::Pin,
};

fn firstn() -> impl Generator<Yield = u64, Return = ()> {
    static move || {
        let mut num = 0;
        let num = &mut num;

        yield *num;
        *num += 1; //~ ERROR: borrow stack

        yield *num;
        *num += 1;

        yield *num;
        *num += 1;
    }
}

fn main() {
    let mut generator_iterator = firstn();
    let mut pin = unsafe { Pin::new_unchecked(&mut generator_iterator) };
    let mut sum = 0;
    while let GeneratorState::Yielded(x) = pin.as_mut().resume() {
        sum += x;
    }
    println!("{}", sum);
}

The reason it fails is that each time through the loop, we call Pin::as_mut, which creates a fresh mutable reference to the generator. Since mutable references are unique, that invalidates the pointer that points from one field of the generator to another.

This is basically a particularly bad instance of #133.

Cc @cramertj @tmandry @nikomatsakis @arielb1

The text was updated successfully, but these errors were encountered:

RalfJung · 2019-06-23T09:15:52Z

In some sense there are two problems here:

When a Pin<&mut T> gets passed around, it gets retagged the same way as an &mut T, assuring uniqueness of this pointer to the entire memory range. This is probably not something we want. So maybe we need a "no retagging for private fields" kind of thing, similar to what we might need for protectors. This is the (relatively) easy part.
However, even just calling Pin::as_mut creates a mutable reference internally (before wrapping it in Pin again). So even if we fix the above, we'd still assert uniqueness here. In some sense it would be more correct if a Pin<&mut T> would actually be represented as a NonNull<T>, as that's a more honest reflection of the aliasing situation: it's not a unique pointer, there can be pointers inside this data structure that alias. This is the hard part.

If we still had PinMut as a separate type, this would be fixable, but with Pin<impl Deref>, that's hard. And even then, map_unchecked_mut still creates a mutable reference and even passes it as a function argument, which is about as strongly asserting uniqueness as we can -- and which we don't want, aliasing pointers are allowed to exist.

RalfJung · 2019-06-25T06:58:09Z

If we ignore the fact that references are wrapped inside the Pin struct, self-referential generators do the equivalent of:

fn main() {
    let mut local = 42;
    let raw_ptr = &mut local as *mut i32; // create raw pointer
    let safe_ref = &mut local; // create a reference, which is unique, and hence invalidates the raw pointer
    println!("{}", unsafe { *raw_ptr }); // UB
}

I explicitly wanted that code to be UB. While raw pointers aliasing with each other is allowed, having a single raw pointer and a mutable reference acts pretty much like having two mutable references -- after all, between the two of them, it's enough if one side does not allow aliasing, since "aliases-with" is a symmetric relation. If we replace raw_ptr by another reference above, the code is rejected by both the borrow checker and Stacked Borrows.

So to fix this problem, I see two general options:

"Hide" references in struct fields from Stacked Borrows. Then the implementation of Pin methods would have to do lots of transmute to avoid ever creating a "bare" reference. And map_unchecked_mut has a problem. It should probably use raw pointers (and RFC for an operator to take a raw reference rfcs#2582 to get a field address). On the other hand, at least we have a plan.
Allow the example code above. We would have to somehow "lazily" activate mutable references. It's a bit like two-phase borrows but worse. I don't have a very concrete idea what this would look like, but I think Stacked Borrows would have to become Tree-shaped Borrows or so -- a stack just does not have enough structure.

HadrienG2 · 2019-06-29T10:46:28Z

@RalfJung: Could this be resolved by turning Pin<&'a mut T> into some abstraction around (&'a UnsafeCell<T>; PhantomData<&'a mut T>) that does not actually hold a reference, but only behaves like one and spawns actual references on demand?

This would likely require turning Pin into Compiler Magic(tm) that is hard to implement for user-defined pointer types, though, and I can imagine backwards-incompatible implications in other areas such as changing the safety contract for extracting mutable references from Pin...

EDIT: Ah, I see that you explored a NonNull-based variant of this strategy above.

RalfJung · 2019-06-29T12:50:41Z

You don't need UnsafeCell, *mut T would do it. And yes that's basically what I had in mind with option (1).

CAD97 · 2019-06-29T13:36:45Z

The way I understand how Pin works, the self referential references borrow their validity from the one in the pin. So under SB, they're retagged from the pin.

The most minimal change that would make pin play nicely with SB I think would be to somehow keep the interior references valid even while the unsafe map_unchecked_mut reference is used.

Could it be possible to not retag for pin's map_unchecked_mut and only pop tags when the reference is used to access that memory location? (This is super spitball, sorry)

RalfJung · 2019-06-29T17:20:31Z

The way I understand how Pin works, the self referential references borrow their validity from the one in the pin. So under SB, they're retagged from the pin.

Correct.

However, then the pin itself eventually gets retagged, and that kills the self-referential borrows. This currently happens all the time, but could be reduced to just "inside the Pin implementation" if we make retag respect privacy, or just generally not enter structs, or so.

Could it be possible to not retag for pin's map_unchecked_mut

Well it'd need a magic marker or so.

and only pop tags when the reference is used to access that memory location? (This is super spitball, sorry)

That's basically option (2) from above.

RalfJung · 2019-08-13T16:12:34Z

#194 indicates that this is a problem with self-referential structs in general, not just self-referential generators. That's not surprising, so I generalized the issue title.

Aaron1011 · 2019-08-22T00:54:19Z

@RalfJung: Related to your example of:

fn main() {
    let mut local = 42;
    let raw_ptr = &mut local as *mut i32; // create raw pointer
    let safe_ref = &mut local; // create a reference, which is unique, and hence invalidates the raw pointer
    println!("{}", unsafe { *raw_ptr }); // UB
}

While working on pin-project, I wanted to write this code:

use std::pin::Pin;

struct Foo {
    // #[pin]
    field1: u8,
    field2: bool
}

struct FooProj<'a> {
    __self_ptr: *mut Foo,
    field1: Pin<&'a mut u8>,
    field2: &'a mut bool
}

impl Foo {
    fn project<'a>(self: Pin<&'a mut Self>) -> FooProj<'a> {
        let this = unsafe { self.get_unchecked_mut() };
        let __self_ptr: *mut Foo = this;
        let field1  = unsafe { Pin::new_unchecked(&mut this.field1) };
        let field2 = &mut this.field2;
        FooProj {
            __self_ptr,
            field1,
            field2
        }
    }
}

impl<'a> FooProj<'a> {
    fn unproject(self) -> Pin<&'a mut Foo> {
        unsafe {
            let this: &mut Foo = &mut *self.__self_ptr;
            Pin::new_unchecked(this)
        }
    }
}

fn main() {
    let mut foo = Foo { field1: 25, field2: true };
    let foo_pin: Pin<&mut Foo> = Pin::new(&mut foo);
    let foo_proj: FooProj = foo_pin.project();
    let foo_orig: Pin<&mut Foo> = foo_proj.unproject();
}

The key thing here is the unproject method. Basically, I want to be able to the following:

Convert an &mut Self to a *mut Self
Create mutable references to fields of Self (&mut self.field, etc.)
Later, upgrade the *mut Self to a &mut Self, after all of the mutable fields references have gone out of scope.

However, Miri flags this as UB for (I believe) a similar reason as your example - creating a mutable reference to a field ends up transitively asserts that we have unique ownership of the base type. Therefore, any pre-existing raw pointers to the base type will be invalidated.

Allowing this kind of pattern would make pin-project much more useful. It would allow the following pattern:

impl MyType {
	fn process(self: Pin<&mut Self>) {
        let this = self.project();

        // Use a pin-projected field - e.g. poll a wrapped future
        ...


        // Construct a new instance of MyType - e.g. a new enum variant
        let new_foo: MyType = ...;
        // Overwrite ourself using Pin::set
        let new_self: Pin<&mut Self> = this.unproject();
        new_self.set(new_foo);
    }

This is especially useful when working with enums - here's a real-world example in Hyper.

However, I can't see a way to avoid creating and later 'upgrading' a raw pointer when trying to safely abstract this pattern in pin-project.

CAD97 · 2019-08-22T01:41:13Z

With arbitrary_self_types, pin-project could take self: &mut Pin<&mut Self> to get a lifetime to tie the projection to, and let NLL take care of the projection lifetime then allow using self again. example.

It is the same kind of reasoning as to why this could be sound: in the self-referential case, it's the whole pointer existing that invalidates the part pointers, though their usage regions are disjoint. In the unproject case, it's the part pointers invalidating the whole pointer, even though they are statically required to be used in disjoint regions.

@CAD97

Based on rust-lang/unsafe-code-guidelines#148 (comment) by @CAD97 Currently, the generated 'project' method takes a 'Pin<&mut Self>', consuming it. This makes it impossible to use the original Pin<&mut Self> after calling project(), since the 'Pin<&mut Self>' has been moved into the the 'Project' method. This makes it impossible to implement useful pattern when working with enums: ```rust enum Foo { Variant1(#[pin] SomeFuture), Variant2(OtherType) } fn process(foo: Pin<&mut Foo>) { match foo.project() { __FooProjection(fut) => { fut.poll(); let new_foo: Foo = ...; foo.set(new_foo); }, _ => {} } } ``` This pattern is common when implementing a Future combinator - an inner future is polled, and then the containing enum is changed to a new variant. However, as soon as 'project()' is called, it becoms imposible to call 'set' on the original 'Pin<&mut Self>'. To support this pattern, this commit changes the 'project' method to take a '&mut Pin<&mut Self>'. The projection types works exactly as before - however, creating it no longer requires consuming the original 'Pin<&mut Self>' Unfortunately, current limitations of Rust prevent us from simply modifiying the signature of the 'project' method in the inherent impl of the projection type. While using 'Pin<&mut Self>' as a receiver is supported on stable rust, using '&mut Pin<&mut Self>' as a receiver requires the unstable `#![feature(arbitrary_self_types)]` For compatibility with stable Rust, we instead dynamically define a new trait, '__{Type}ProjectionTrait', where {Type} is the name of the type with the `#[pin_project]` attribute. This trait looks like this: ```rust trait __FooProjectionTrait { fn project('a &mut self) -> __FooProjection<'a>; } ``` It is then implemented for `Pin<&mut {Type}>`. This allows the `project` method to be invoked on `&mut Pin<&mut {Type}>`, which is what we want. If Generic Associated Types (rust-lang/rust#44265) were implemented and stablized, we could use a single trait for all pin projections: ```rust trait Projectable { type Projection<'a>; fn project(&'a mut self) -> Self::Projection<'a>; } ``` However, Generic Associated Types are not even implemented on nightly yet, so we need for generate a new trait per type for the forseeable future.

@CAD97

Based on rust-lang/unsafe-code-guidelines#148 (comment) by @CAD97 Currently, the generated 'project' method takes a 'Pin<&mut Self>', consuming it. This makes it impossible to use the original Pin<&mut Self> after calling project(), since the 'Pin<&mut Self>' has been moved into the the 'Project' method. This makes it impossible to implement useful pattern when working with enums: ```rust enum Foo { Variant1(#[pin] SomeFuture), Variant2(OtherType) } fn process(foo: Pin<&mut Foo>) { match foo.project() { __FooProjection(fut) => { fut.poll(); let new_foo: Foo = ...; foo.set(new_foo); }, _ => {} } } ``` This pattern is common when implementing a Future combinator - an inner future is polled, and then the containing enum is changed to a new variant. However, as soon as 'project()' is called, it becoms imposible to call 'set' on the original 'Pin<&mut Self>'. To support this pattern, this commit changes the 'project' method to take a '&mut Pin<&mut Self>'. The projection types works exactly as before - however, creating it no longer requires consuming the original 'Pin<&mut Self>' Unfortunately, current limitations of Rust prevent us from simply modifiying the signature of the 'project' method in the inherent impl of the projection type. While using 'Pin<&mut Self>' as a receiver is supported on stable rust, using '&mut Pin<&mut Self>' as a receiver requires the unstable `#![feature(arbitrary_self_types)]` For compatibility with stable Rust, we instead dynamically define a new trait, '__{Type}ProjectionTrait', where {Type} is the name of the type with the `#[pin_project]` attribute. This trait looks like this: ```rust trait __FooProjectionTrait { fn project(&'a mut self) -> __FooProjection<'a>; } ``` It is then implemented for `Pin<&mut {Type}>`. This allows the `project` method to be invoked on `&mut Pin<&mut {Type}>`, which is what we want. If Generic Associated Types (rust-lang/rust#44265) were implemented and stablized, we could use a single trait for all pin projections: ```rust trait Projectable { type Projection<'a>; fn project(&'a mut self) -> Self::Projection<'a>; } ``` However, Generic Associated Types are not even implemented on nightly yet, so we need for generate a new trait per type for the forseeable future.

@CAD97

47: Make generated 'project' reference take an '&mut Pin<&mut Self>' r=taiki-e a=Aaron1011 Based on rust-lang/unsafe-code-guidelines#148 (comment) by @CAD97 Currently, the generated 'project' method takes a 'Pin<&mut Self>', consuming it. This makes it impossible to use the original Pin<&mut Self> after calling project(), since the 'Pin<&mut Self>' has been moved into the the 'Project' method. This makes it impossible to implement useful pattern when working with enums: ```rust enum Foo { Variant1(#[pin] SomeFuture), Variant2(OtherType) } fn process(foo: Pin<&mut Foo>) { match foo.project() { __FooProjection(fut) => { fut.poll(); let new_foo: Foo = ...; foo.set(new_foo); }, _ => {} } } ``` This pattern is common when implementing a Future combinator - an inner future is polled, and then the containing enum is changed to a new variant. However, as soon as 'project()' is called, it becoms imposible to call 'set' on the original 'Pin<&mut Self>'. To support this pattern, this commit changes the 'project' method to take a '&mut Pin<&mut Self>'. The projection types work exactly as before - however, creating it no longer requires consuming the original 'Pin<&mut Self>' Unfortunately, current limitations of Rust prevent us from simply modifying the signature of the 'project' method in the inherent impl of the projection type. While using 'Pin<&mut Self>' as a receiver is supported on stable rust, using '&mut Pin<&mut Self>' as a receiver requires the unstable `#![feature(arbitrary_self_types)]` For compatibility with stable Rust, we instead dynamically define a new trait, '__{Type}ProjectionTrait', where {Type} is the name of the type with the `#[pin_project]` attribute. This trait looks like this: ```rust trait __FooProjectionTrait { fn project(&'a mut self) -> __FooProjection<'a>; } ``` It is then implemented for `Pin<&mut {Type}>`. This allows the `project` method to be invoked on `&mut Pin<&mut {Type}>`, which is what we want. If Generic Associated Types (rust-lang/rust#44265) were implemented and stabilized, we could use a single trait for all pin projections: ```rust trait Projectable { type Projection<'a>; fn project(&'a mut self) -> Self::Projection<'a>; } ``` However, Generic Associated Types are not even implemented on nightly yet, so we need to generate a new trait per type for the foreseeable future. Co-authored-by: Aaron Hill <[email protected]>

RalfJung · 2019-08-24T16:16:59Z

creating a mutable reference to a field ends up transitively asserts that we have unique ownership of the base type

I don't understand what you are trying to say here. The type of the referent doesn't really matter here. (It only matters for its size and where the UnsafeCell are.)

Therefore, any pre-existing raw pointers to the base type will be invalidated.

Only raw pointers that are not "parents" of the mutable reference get invalidated.

So, I think you can fix your code by deriving FooProj::field* from FooProj::__self_ptr.

@sebzim4500

Fixes actix#1321 A better fix would be to change `MessageBody` to take a `Pin<&mut Self>`, rather than a `Pin<&mut Self>`. This will avoid requiring the use of `Box` for all consumers by allowing the caller to determine how to pin the `MessageBody` implementation (e.g. via stack pinning). However, doing so is a breaking change that will affect every user of `MessageBody`. By pinning the inner stream ourselves, we can fix the undefined behavior without breaking the API. I've included @sebzim4500's reproduction case as a new test case. However, due to the nature of undefined behavior, this could pass (and not segfault) even if underlying issue were to regress. Unfortunately, until rust-lang/unsafe-code-guidelines#148 is resolved, it's not even possible to write a Miri test that will pass when the bug is fixed.

@sebzim4500

Fixes actix#1321 A better fix would be to change `MessageBody` to take a `Pin<&mut Self>`, rather than a `Pin<&mut Self>`. This will avoid requiring the use of `Box` for all consumers by allowing the caller to determine how to pin the `MessageBody` implementation (e.g. via stack pinning). However, doing so is a breaking change that will affect every user of `MessageBody`. By pinning the inner stream ourselves, we can fix the undefined behavior without breaking the API. I've included @sebzim4500's reproduction case as a new test case. However, due to the nature of undefined behavior, this could pass (and not segfault) even if underlying issue were to regress. Unfortunately, until rust-lang/unsafe-code-guidelines#148 is resolved, it's not even possible to write a Miri test that will pass when the bug is fixed.

@sebzim4500

Fixes #1321 A better fix would be to change `MessageBody` to take a `Pin<&mut Self>`, rather than a `Pin<&mut Self>`. This will avoid requiring the use of `Box` for all consumers by allowing the caller to determine how to pin the `MessageBody` implementation (e.g. via stack pinning). However, doing so is a breaking change that will affect every user of `MessageBody`. By pinning the inner stream ourselves, we can fix the undefined behavior without breaking the API. I've included @sebzim4500's reproduction case as a new test case. However, due to the nature of undefined behavior, this could pass (and not segfault) even if underlying issue were to regress. Unfortunately, until rust-lang/unsafe-code-guidelines#148 is resolved, it's not even possible to write a Miri test that will pass when the bug is fixed. Co-authored-by: Yuki Okushi <[email protected]>

Dante-Broggi · 2021-01-14T18:43:59Z

As a passing thought:
Would the situation improve if there were a core lang type (name TBD) here called UnsafeWindow<T> with the fundamental property, an inverse of UnsafeCell<T>, that a &mut UnsafeWindow<T> is permitted simultaneously with &T to its field?

RalfJung · 2021-01-14T18:45:51Z

The property we need of some UnsafeAlias type is that two &mut UnsafeAlias<T> may alias. I don't see an immediate reason for why this would have to interact with & in interesting ways.

disable test with self-referential generator on Miri Running the libcore test suite in Miri currently fails due to the known incompatibility of self-referential generators with Miri's aliasing checks (rust-lang/unsafe-code-guidelines#148). So let's disable that test in Miri for now.

RalfJung · 2022-01-01T18:06:17Z

rust-lang/miri#1952 could help with this by disabling uniqueness of mutable references for !Unpin types -- however, there is some risk that too many types are !Unpin, thus disabling uniqueness in too many cases.

I wonder what people think about this.

Darksonn · 2022-01-01T21:31:24Z

I think it would be very interesting to have a version of miri that disables uniqueness for !Unpin types. We have tried to make the Tokio types always be !Unpin when they are intrusively shared, but it would definitely not surprise me if it's not done perfectly. Much of Tokio's codebase is not testable with miri because of this issue.

One particular concern I have is regarding what happens when you have an Unpin field of a !Unpin type.

RalfJung · 2022-01-02T09:22:12Z

One particular concern I have is regarding what happens when you have an Unpin field of a !Unpin type.

The moment you create a reference to that field, it would require uniqueness.

RalfJung · 2022-01-02T09:25:24Z

have a version of miri that disables uniqueness for !Unpin types

As in, make this configurable via a flag? That's possible, but then the question remains what the default should be.

Darksonn · 2022-01-02T09:28:04Z

Whether it's a flag or not is not that important to me.

The moment you create a reference to that field, it would require uniqueness.

Yes, that was the impression I got as well. In Tokio I have been doing this because it's unclear to me exactly what is required:

https://github.com/tokio-rs/tokio/blob/12dd06336d2af8c2d735d4d9e3dc0454ad7942a0/tokio/src/util/linked_list.rs#L285-L334

However, we haven't been doing the same for all structs containing a Pointers. Tokio's MSRV is too old for the addr_of! macro, so it's pretty difficult to do it everywhere. It's also difficult if types are not Copy.

RalfJung · 2022-01-02T11:04:34Z

Hm, I don't quite understand what that Pointers struct is about, but indeed without addr_of! some code cannot be written properly. Would it be an option to have a build.rs set a cfg flag such that on recent enough Rust, addr_of! is used, but older Rust fall back to &expr as *const _? (Somewhat like the maybe-uninit crate.)

But anyway that seems unrelated to self-referential generators, so we should probably move the discussion elsewhere (e.g. Zulip).

exclude mutable references to !Unpin types from uniqueness guarantees This basically works around rust-lang/unsafe-code-guidelines#148 by not requiring uniqueness any more for mutable references to self-referential generators. That corresponds to [the same work-around that was applied in rustc itself](https://github.com/rust-lang/rust/blob/b81553267437627af63c79c1a20c73af865a842a/compiler/rustc_middle/src/ty/layout.rs#L2482). I am not entirely sure if this is a good idea since it might hide too many errors in case types are "accidentally" `!Unpin`. OTOH, our test suite still passes, and to my knowledge the vast majority of types is `Unpin`. (`place.layout.ty` is monomorphic, we should always exactly know which type this is.)

mitsuhiko · 2022-02-18T20:28:18Z

I believe I'm running into a variation of this here: mitsuhiko/deser#37 — While I don't have a generator, I have the situation where I am trying to stash away a value temporarily on an iterator like type for one iteration and the returning the value invalidates all pointers.

While what I'm doing is probably not a very common issue, it seems like you can run into this in the absence of generators, futures and pin as well.

thomcc · 2022-02-18T20:30:01Z

Yes, it's definitely a thing that happens outside of the case that's mentioned at the start.

RalfJung · 2022-02-18T21:02:22Z

This issue here is specific about self-referential data structures though, not sure how those would come up in an iterator? So on first sight that does not really sound like the same problem.

mitsuhiko · 2022-02-18T22:40:25Z

@RalfJung it's not a traditional iterator, it's a struct that is iterated like this:

while let Some(value) = thing.next()? { ... }

And it works by stashing data onto self for next() to return a borrow to. Since I create self referential data within the "iterator" to make data survive until the next iteration in the form of some state machine, I am getting some pointers invalidated presumably because fn next has &mut self. That's at least my interpretation of what is happening.

CAD97 · 2022-05-09T17:43:55Z

Cross-linking recent zulip discussion about "UnsafeMutCell": https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/aliased.20mutability

JakobDegen · 2023-08-01T16:45:41Z

Visiting for backlog bonanza. Retitling to clarify that this is not SB specific

RalfJung · 2023-08-01T17:04:12Z

I also just posted an RFC intended to properly resolve this :) rust-lang/rfcs#3467

WarpspeedSCP · 2023-08-19T03:25:44Z

As an observer, a thought occurred regarding the UnsafeWindow proposal. Would it be possible to prevent this type from ever being referenced? As in, it should be treated effectively like an UnsafeCell, but creating direct references to an UnsafeWindow should be disallowed.

Based on a minute's worth of thought it seems like if UnsafeWindow were allowed to be turned into a reference, we run into the same set of problems every other proposal has, where we end up having to make exemptions for certain referencing patterns wholesale where we could instead restrict it to certain regions through api enforcement.

It feels like an approach where UnsafeWindow would instead somehow provide non aliasing mutable references to the inner value may allow for easier restrictions on what is allowed in general while still allowing the self referential behaviour.

Thinking in terms of mutability, Id say UnsafeWindow would behave like UnsafeCell, as in an immutable UnsafeWindow would still allow for multiple mutable references to the inner value to exist.

In summary, UnsafeWindow would be ownership only, and dereferencing an unsafe window should result in, say, a new reference that is implicitly assumed to be non aliasing. Usage in ways that allow the reference to exist outside of the variable's scope would be UB, but I can' figure out if there is a way to statically disallow such a situation, aince if we attach ifetimes to the created references it would imply they are tied to the UnsafeWindow and we may end up looping around to the aliasing mutable reference problem again.

Welp, that RFC sort of is exactly what I envisioned.

RalfJung added the A-aliasing-model Topic: Related to the aliasing model (e.g. Stacked/Tree Borrows) label Jun 21, 2019

RalfJung mentioned this issue Jun 29, 2019

[Stabilization] async/await MVP rust-lang/rust#62149

Closed

4 tasks

RalfJung mentioned this issue Aug 3, 2019

Test whether self-referential futures are compatible with stacked borrows rust-lang/miri#532

Closed

RalfJung mentioned this issue Aug 13, 2019

Stacked Borrows vs inner pointers into "stable-deref" types #194

Closed

RalfJung changed the title ~~Stacked Borrows vs self-referential generators~~ Stacked Borrows vs self-referential structs Aug 13, 2019

RalfJung added the C-open-question Category: An open question that we should revisit label Aug 14, 2019

Centril mentioned this issue Aug 21, 2019

Stabilize async_await in Rust 1.39.0 rust-lang/rust#63209

Merged

9 tasks

Aaron1011 mentioned this issue Aug 23, 2019

Make generated 'project' reference take an '&mut Pin<&mut Self>' taiki-e/pin-project#47

Merged

jyn514 mentioned this issue Dec 3, 2019

Miri gives an error when resolving strings Robbepop/string-interner#15

Closed

Aaron1011 mentioned this issue Jan 28, 2020

Use Pin<Box<S>> in BodyStream and SizedStream actix/actix-web#1328

Merged

RalfJung mentioned this issue Mar 27, 2020

Stacked Borrows: asserting uniqueness too early? Should we allow the optimizer to add spurious stores? #133

Open

RalfJung mentioned this issue Jan 8, 2021

Odd behaviour on self-referential types that use UnsafeCell rust-lang/miri#1665

Closed

RalfJung mentioned this issue Aug 1, 2021

miri accepts when embedded UnsafeCell in mutable Pin reference is changed rust-lang/miri#1860

Closed

RalfJung mentioned this issue Nov 9, 2021

Miri UB warning about compat feature rust-lang/futures-rs#2514

Open

RalfJung mentioned this issue Nov 29, 2021

Compiler optimizations considered harmful in safe function in "unsafe module" rust-lang/rust-memory-model#40

Closed

dtolnay mentioned this issue Dec 12, 2021

3 case studies for -Zmiri-tag-raw-pointers rust-lang/miri#1936

Closed

RalfJung mentioned this issue Dec 20, 2021

disable test with self-referential generator on Miri rust-lang/rust#92121

Merged

RalfJung mentioned this issue Jan 1, 2022

exclude mutable references to !Unpin types from uniqueness guarantees rust-lang/miri#1952

Merged

RalfJung mentioned this issue Apr 13, 2022

Strip noalias from pointer derived from mutable ref #327

Closed

RalfJung mentioned this issue May 9, 2022

What are the uniqueness guarantees of Box and Vec? #326

Open

GoldsteinE mentioned this issue Dec 1, 2022

futures-channel fails under Miri rust-lang/futures-rs#2669

Closed

JakobDegen added the S-pending-design Status: Resolving this issue requires addressing some open design questions label Aug 1, 2023

JakobDegen changed the title ~~Stacked Borrows vs self-referential structs~~ Mutable references vs self-referential structs Aug 1, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mutable references vs self-referential structs #148

Mutable references vs self-referential structs #148

RalfJung commented Jun 21, 2019

RalfJung commented Jun 23, 2019

RalfJung commented Jun 25, 2019 •

edited

Loading

HadrienG2 commented Jun 29, 2019 •

edited

Loading

RalfJung commented Jun 29, 2019 •

edited

Loading

CAD97 commented Jun 29, 2019

RalfJung commented Jun 29, 2019

RalfJung commented Aug 13, 2019

Aaron1011 commented Aug 22, 2019 •

edited

Loading

CAD97 commented Aug 22, 2019

RalfJung commented Aug 24, 2019

Dante-Broggi commented Jan 14, 2021

RalfJung commented Jan 14, 2021

RalfJung commented Jan 1, 2022

Darksonn commented Jan 1, 2022

RalfJung commented Jan 2, 2022

RalfJung commented Jan 2, 2022

Darksonn commented Jan 2, 2022 •

edited

Loading

RalfJung commented Jan 2, 2022

mitsuhiko commented Feb 18, 2022

thomcc commented Feb 18, 2022

RalfJung commented Feb 18, 2022

mitsuhiko commented Feb 18, 2022 •

edited

Loading

CAD97 commented May 9, 2022 •

edited

Loading

JakobDegen commented Aug 1, 2023

RalfJung commented Aug 1, 2023 via email

WarpspeedSCP commented Aug 19, 2023 •

edited

Loading

Mutable references vs self-referential structs #148

Mutable references vs self-referential structs #148

Comments

RalfJung commented Jun 21, 2019

RalfJung commented Jun 23, 2019

RalfJung commented Jun 25, 2019 • edited Loading

HadrienG2 commented Jun 29, 2019 • edited Loading

RalfJung commented Jun 29, 2019 • edited Loading

CAD97 commented Jun 29, 2019

RalfJung commented Jun 29, 2019

RalfJung commented Aug 13, 2019

Aaron1011 commented Aug 22, 2019 • edited Loading

CAD97 commented Aug 22, 2019

RalfJung commented Aug 24, 2019

Dante-Broggi commented Jan 14, 2021

RalfJung commented Jan 14, 2021

RalfJung commented Jan 1, 2022

Darksonn commented Jan 1, 2022

RalfJung commented Jan 2, 2022

RalfJung commented Jan 2, 2022

Darksonn commented Jan 2, 2022 • edited Loading

RalfJung commented Jan 2, 2022

mitsuhiko commented Feb 18, 2022

thomcc commented Feb 18, 2022

RalfJung commented Feb 18, 2022

mitsuhiko commented Feb 18, 2022 • edited Loading

CAD97 commented May 9, 2022 • edited Loading

JakobDegen commented Aug 1, 2023

RalfJung commented Aug 1, 2023 via email

WarpspeedSCP commented Aug 19, 2023 • edited Loading

RalfJung commented Jun 25, 2019 •

edited

Loading

HadrienG2 commented Jun 29, 2019 •

edited

Loading

RalfJung commented Jun 29, 2019 •

edited

Loading

Aaron1011 commented Aug 22, 2019 •

edited

Loading

Darksonn commented Jan 2, 2022 •

edited

Loading

mitsuhiko commented Feb 18, 2022 •

edited

Loading

CAD97 commented May 9, 2022 •

edited

Loading

WarpspeedSCP commented Aug 19, 2023 •

edited

Loading