Polling the wrapped future previously had several reborrow operations, such as in the use of map_unchecked_mut and in the implementation of as_mut_ptr. This caused issues when running under miri in the stress_drop_sender test.

This change re-implements these problematic cases to avoid reborrows, either through using Pin::get_unchecked_mut or transmuting pointers rather than borrowing and casting.

Fixes https://github.com/microsoft/stackfuture/issues/9

Thanks to @jstarks for the suggestion of how to do this!

This also bumps the version in Cargo.toml to 0.3.0 since it's a breaking change now that StackFuture::from will fail to compile in cases where it would have panicked at runtime.

Signed-off-by: Xuanwo [email protected]

This PR adds fmt, check and clippy for CI. I also added rust-toolchain.toml and rustfmt.toml to make our contributors' lives easier.

Fix #4

Hi! I’ve recently created a similar crate, but without dynamic dispatch and with automatic size calculation and Send/Sync inference, and found a problem with using .map_unchecked_mut() in .poll().

This line:

https://github.com/microsoft/stackfuture/blob/ae58939/src/lib.rs#L207

causes a retag of the whole byte array, invalidating all internal references inside of a future. To prevent this, you should directly transmute Pin<&mut MaybeUninit[u8; _]> instead of mapping.

This is a simple testcase that fails under Miri (adapted from futures-rs test suite):

use futures::{
    channel::mpsc,
    executor::block_on,
    sink::SinkExt as _,
    stream::{Stream, StreamExt as _},
};
use stackfuture::StackFuture;
use std::thread;

#[test]
fn stress_drop_sender() {
    const ITER: usize = if cfg!(miri) { 100 } else { 10000 };

    fn list() -> impl Stream<Item = i32> {
        let (tx, rx) = mpsc::channel(1);
        thread::spawn(move || {
            block_on(send_one_two_three(tx));
        });
        rx
    }

    for _ in 0..ITER {
        let v: Vec<_> = block_on(list().collect());
        assert_eq!(v, vec![1, 2, 3]);
    }
}

fn send_one_two_three(mut tx: mpsc::Sender<i32>) -> StackFuture<'static, (), 512> {
    StackFuture::from(async move {
        for i in 1..=3 {
            tx.send(i).await.unwrap();
        }
    })
}

This is perhaps an over-designed error type, but it provides enough information to figure out why the conversion failed, which can help the programmer fix it.

This PR also includes #20, so review that first and I'll merge that one and rebase this one before merging it.

It would be nice to add a impl std::error::Error for IntoStackFutureError, but for now we are a no_std crate and I wasn't sure adding a no_std feature would be worth it just for that impl. I think the plan is for the Error trait to become part of core someday, so we could just wait until then.

This gives us a way to support any size future with a small value optimization. The from_or_boxed constructor attempts to store the wrapped future in StackFuture's reserved space, but if it cannot then it store the future in a box and wrap the box instead.

Note that doing this requires adding an "alloc" feature so this crate can continue to be used in pure no_std environments.

This also changes the panic behavior of try_from to not panic on alignment errors. To make it easier to determine why something went wrong, we make the has_*_for* functions public. We also adjust the panic messages in StackFuture::from to make it clear which conditions failed.

Finally, we introduce a testing matrix for GitHub actions to make sure we run tests both with and without allocation.

It'd be helpful to have a way to shrink (or less commonly, grow) a StackFuture. For example, sometimes you have an object that implements a trait and needs to forward calls to another object that implements the same trait. Right now that's impossible with StackFuture without boxing the child future because otherwise you'd have to have a future contain a future that's the same size as itself. That said, there will usually be some extra space so we might be able to dynamically shrink a StackFuture.

The signature would probably be something like:

fn resize<const NEW_SIZE: usize>(self) -> Result<StackFuture<T, NEW_SIZE>, Self>;

Then using this would look something like:

impl Foo for MyObject {
    fn bar(&self) -> StackFuture<(), 1000> {
        match self.sub_object.bar().resize::<{500}>() {
            Ok(f) => f.await,
            Err(original) => Box::pin(original).await,
        }
    }
}

The idea here is we'd try to fit the future into a smaller container, but if it doesn't fit then the resize returns the original future and we can either decide to pay the allocation cost (as we did in this example) or give up.

The idea here is to make a macro similar to the #[async_trait] one from the async trait crate. Using it would look something like this:

#[stackfuture::async_trait(4096)]
trait Foo {
    async fn bar(&self) -> i32;
}

The macro would then expand to something like (along with whatever lifetime annotations are needed:

trait Foo {
    fn bar(&self) -> StackFuture<i32, { 4096 }>`;
}

We'd do a similar thing for impls as well.