profile
viewpoint

aturon/rfcs 59

RFCs for changes to Rust

cramertj/EitherN-rs 8

Rust library allowing for quick, ad-hoc sum types

cramertj/impl-trait-goals 8

An (experimental) RFC repo devoted to Rust's `impl Trait`.

cramertj/jack-sys 1

Low-level Rust bindings to the JACK audio API.

benbrittain/rustyline 0

Readline Implementation in Rust

cramertj/async-await 0

Run Await With Me - RustConf 2018 Async/Await Training

cramertj/async-await-class 0

Stubs of the Code used with the RustConf 2018 Async/Await Class

pull request commentrust-lang/rust

Make error message clearer about creating new module

r=me with travis fixed up.

kornelski

comment created time in 4 hours

Pull request review commentrust-lang/rust

docs: add mention of async blocks in move keyword docs

 mod mod_keyword {} /// // x is no longer available /// ``` ///+/// `move` is also valid before an async block.+///+/// ```rust+/// let capture = "hello";+/// async move {

In the change to move to async blocks here, it looks like the let binding was also removed-- I'd leave that in, since this block on its own won't cause any code to run.

Pulkit07

comment created time in 5 hours

pull request commentrust-lang/rust

Add `take_...` functions to slices

You seem to be using (hand rolled versions of) these methods fairly often. Can you tell us how you usually use them?

Yep! I use them when writing custom serialization / deserialization code to/from byte slices. In the case of invalid input that isn't of the appropriate length, I always want to generate an error rather than a panic, as I don't want invalid input (which is often from an untrusted source) to result in a crash of the program performing the serialization or deserialization (often a long-running server). If these APIs panic'd, that would (1) mean that I'd have to insert extra manual checks before every use, and (2) if I missed any checks, malformed input could result in a crash.

cramertj

comment created time in a day

Pull request review commentrust-lang/rust

docs: add mention of async blocks in move keyword docs

 mod mod_keyword {} /// // x is no longer available /// ``` ///+/// `move` is also valid before an async block.+///+/// ```rust+/// let capture = "hello";+/// let closure = async move || {

This doc says "async block" above, but uses an async closure and says "async closure" below. async closures are not stable and shouldn't be mentioned in these docs.

Pulkit07

comment created time in a day

pull request commentrust-lang/rust

Clean up TypeFlags

r=me with travis

matthewjasper

comment created time in 2 days

pull request commentrust-lang/rust

Remove "unnecessary `unsafe` block in `unsafe` fn" lint

if I see no unsafe blocks in my unsafe function, is that function body entirely unsafe (with lots of unsafe calls) or entirely safe code? That's something that @cramertj's proposal, AFAICT, does not solve, in the sense that when transitioning you'd almost want to add a let () = unsafe { () }; to every unsafe function or something like that just to opt-in to the new behavior.

Presumably you'd set #![deny(the_new_warning)] instead.

LeSeulArtichaut

comment created time in 2 days

delete branch cramertj/futures-rs

delete branch : 0.3.0-alpha.15

delete time in 3 days

issue closedrust-lang/futures-rs

Possibly over-aggressive dependency changes due to release process/workspace use.

I'm spotting some odd behaviour, and I suspect its due to the workspace-oriented release flow.

For example comparing futures-sink 0.3.1 with futures-sink 0.3.4 yields no obvious changes to me that would explain why futures-channel 0.3.4 would require it, as opposed to futures-channel 0.3.1.

There's metadata changes, but they look cosmetic.

Ideally, dependencies should declare upgrades only out of necessity, and let cargo and other build chains decide when they need to upgrade a dependency.

But as it stands, it looks to be creating a bunch of "busywork" for downstream to replicate, without a tangible benefit.

I don't oppose publishing releases to fix cosmetic metadata changes, just having newer releases of other things require those changes produces more problems for the consumer side than I think is worth it.

closed time in 3 days

kentfredric

issue commentrust-lang/futures-rs

Possibly over-aggressive dependency changes due to release process/workspace use.

Previously, futures-sink required futures-channel. That was changed to work the other way around, and instead use feature flags to disable the integration.

kentfredric

comment created time in 3 days

issue closedrust-lang/futures-rs

can Mutex be used in Future?

use futures_util::lock::Mutex;
use std::future::Future;
use std::pin::Pin;
use std::sync::Arc;
use std::task::Context;
use std::task::Poll;

#[derive(Debug, Clone)]
struct A {
    a: Arc<Mutex<i32>>,
}
impl Future for A {
    type Output = ();

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        let mut a = self.a.lock();
        let a = Pin::new(&mut a).poll(cx);
        return match a {
            std::task::Poll::Pending => std::task::Poll::Pending,
            std::task::Poll::Ready(n) => {
                println!("A poll ={}", *n);
                std::task::Poll::Ready(())
            }
        };
    }
}

pub async fn test_mutex() {
    let a = A {
        a: Arc::new(Mutex::new(3)),
    };
    let a2 = a.clone();
    println!("call spawn");
    tokio::spawn(async move {
        println!("a2 start");
        let a2 = a2.a.lock().await;
        std::thread::sleep(std::time::Duration::from_millis(100));
        println!("a2={}", *a2);
    });

    std::thread::sleep(std::time::Duration::from_millis(10));
    println!("a start await");
    a.await;
    println!("a await complete");
}

test_mutex will never return. it's the problem of MutexLockFuture which deregister itself when drop.

Is this right?

closed time in 3 days

nkbai

issue commentrust-lang/futures-rs

can Mutex be used in Future?

The mutex type is not designed to be recreated every time in a poll-- it's intended to be kept around until it can be woken up. The task won't receive a wakeup if the mutex is dropped.

nkbai

comment created time in 3 days

pull request commentrust-lang/futures-rs

Remove the Send bound on the output type of RemoteHandle.

Thanks for the PR! It took me a minute to evaluate, but I don't see a reason why this bound would be required. I'm guessing it might've been a holdover from a previous iteration which expected to be spawning the remote handle onto a task that could run on another thread.

najamelan

comment created time in 3 days

push eventrust-lang/futures-rs

Naja Melan

commit sha 56980e76b9eb9827d56cdbbeaf28a2f018a89a16

Remove the Send bound on the output type of RemoteHandle. Currently Future is only implemented for RemoteHandle if T: Send + 'static I think these bounds don't do anything useful, yet disable valid use cases of the API. The compiler doesn't require them and I can find no good reason for them to be there. In particular if output is not Send, nor will the Remote or the RemoteHandle. Nothing can move to other threads, and if the future panics, the thread will unwind. Seems completely valid to allow that. For 'static, I find it harder to imagine what all the possible consequences might be, but I think it has no reason for being there. I feel less confident to propose a PR to remove it than for Send, so I left it for now.

view details

push time in 3 days

PR merged rust-lang/futures-rs

Reviewers
Remove the Send bound on the output type of RemoteHandle.

Currently Future is only implemented for RemoteHandle<T> if T: Send + 'static

I think these bounds don't do anything useful, yet disable valid use cases of the API. The compiler doesn't require them and I can find no good reason for them to be there.

In particular if output is not Send, nor will the Remote or the RemoteHandle. Nothing can move to other threads, and if the future panics, the thread will unwind. Seems completely valid to allow that.

As for 'static, I find it harder to imagine what all the possible consequences might be, but I think it has no reason for being there. I feel less confident to propose a PR to remove it than for Send, so I left it for now.

If others agree that it's fine to remove it I can update the PR.

The risk is that if ever I'm mistaken and we need to re-add the bounds later, that would be a breaking change.

+1 -1

0 comment

1 changed file

najamelan

pr closed time in 3 days

push eventrust-lang/futures-rs

Jon Gjengset

commit sha c858a2b253083abad8d429aa4ed21620548c8872

util: Relax bounds for FuturesUnordered There is no need for the `FuturesUnordered` constructors to require that the provided `Fut` type implements `Future`. It needlessly requires callers to also propagate that bound onto their constructors, all the way up the chain. This patch removes the bounds except where necessary, specifically for the `impl Stream`.

view details

push time in 3 days

PR merged rust-lang/futures-rs

util: Relax bounds for FuturesUnordered

There is no need for the FuturesUnordered constructors to require that the provided Fut type implements Future. It needlessly requires callers to also propagate that bound onto their constructors, all the way up the chain. This patch removes the bounds except where necessary, specifically for the impl Stream.

+8 -10

1 comment

1 changed file

jonhoo

pr closed time in 3 days

pull request commentrust-lang/futures-rs

util: Relax bounds for FuturesUnordered

Somewhat sad that this is the best way forward given the eventual plan for implied bounds, but I suppose it's the standard way of doing things for now.

jonhoo

comment created time in 3 days

pull request commentrust-lang/rust

Add `take_...` functions to slices

Only that I haven't had time for this recently, and that I still have doubts about a panicking API as opposed to an Option-based one, which I personally prefer and find more flexible.

An Option-based API can satisfy both panicking and non-panicking usecases via expect, where the panicking API still requires that users who wish to avoid panics duplicate this code themselves. I believe most of the APIs on slices which panic have non-panicking alternatives, but I don't wish to duplicate this already "interesting" API surface.

I'll try to have this PR updated soon-- thank you for the ping.

cramertj

comment created time in 3 days

push eventrust-lang/futures-rs

Oleg Nosov

commit sha dde9766fff8371dae4464ead06ed560702d64b70

Add `StreamExt::flat_map` (#2068)

view details

push time in 3 days

PR merged rust-lang/futures-rs

Add `StreamExt::flat_map`

This combinator acts like https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flat_map but for Streams.

+231 -6

0 comment

6 changed files

olegnn

pr closed time in 3 days

issue commenttensorflow/federated

custom_federated_algorithms_2 + collab = error

@pnzr00t Yes, the situation around docs versioning is unfortunate at the moment, and we're working to get this resolved internally. Thank you for your patience, and sorry for the confusion!

pnzr00t

comment created time in 3 days

pull request commentrust-lang/rust

Mark attributes consumed by `check_mod_attrs` as normal

r? @Centril

tmiasko

comment created time in 3 days

pull request commentrust-lang/rust

librustc_typeck: remove loop that never actually loops

r? @varkor

matthiaskrgr

comment created time in 3 days

pull request commentrust-lang/rust

Remove "unnecessary `unsafe` block in `unsafe` fn" lint

I guess @Mark-Simulacrum you are arguing that it would be better to swap the lint "atomically", i.e., go in one step from linting against unsafe blocks towards linting to have people add them?

It does seem like it's unfortunate to have an intermediate state in which folks have some unsafe blocks in their unsafe functions, but those blocks do not surround all unsafe calls. Perhaps we should immediately start linting on unsafe calls outside of unsafe blocks if you have formerly-unnecessary unsafe blocks. This shouldn't cause any warnings on code that didn't have warnings before (swapping one warning for another), and will in some cases unlock the desired end behavior on a speedier timeline.

LeSeulArtichaut

comment created time in 3 days

pull request commentrust-lang/rust

Improve external MinGW detection

Ah, my bad, thanks for the link! LGTM then.

@bors r+

mati865

comment created time in 6 days

pull request commentrust-lang/rust

Improve external MinGW detection

I wonder if this should perhaps reuse the get_file_path tool added in https://github.com/rust-lang/rust/pull/56397/files? It seems like this is doing something very similar.

mati865

comment created time in 6 days

pull request commentrust-lang/rust

Remove experimental chalk option

r? @nikomatsakis

CAD97

comment created time in 9 days

pull request commentrust-lang/rust

[WIP] Implement new asm! syntax from RFC 2850

r? @oli-obk or @nagisa maybe?

Amanieu

comment created time in 13 days

pull request commentrust-lang/futures-rs

Misc docs fixes

Thanks!

olegnn

comment created time in 14 days

push eventrust-lang/futures-rs

Oleg Nosov

commit sha c19d43f750856904ff66e3d06b293185e2729b84

Misc docs fixes (#2067)

view details

push time in 14 days

PR merged rust-lang/futures-rs

Misc docs fixes
  • Specified impossibility to capture item's references into futures (https://github.com/rust-lang/futures-rs/pull/2044#discussion_r369249321)
  • Corrected order of split to (Sink, Stream) in docs
  • Other fixes
+24 -21

0 comment

6 changed files

olegnn

pr closed time in 14 days

push eventrust-lang/futures-rs

Naja Melan

commit sha c8f39191095f4c780b498dfd775ce9ec3cb78b79

Clarify catch_unwind behavior of RemoteHandle. (#2080)

view details

push time in 14 days

PR merged rust-lang/futures-rs

Reviewers
Clarify catch_unwind behavior of RemoteHandle.

Since this is a complicated subject, I thought it good the docs shed some clarity on the behavior of RemoteHandle.

Also removes a confusing comment from the code which no longer accurately describes what's happening (after prior refactoring).

+16 -3

1 comment

1 changed file

najamelan

pr closed time in 14 days

pull request commentrust-lang/futures-rs

Clarify catch_unwind behavior of RemoteHandle.

This looks good to me!

najamelan

comment created time in 14 days

push eventnajamelan/futures-rs

Taylor Cramer

commit sha 886a97e59ce07bb5bb227b7a8e09dd9cfb3c8979

Update remote_handle.rs

view details

push time in 14 days

Pull request review commentrust-lang/futures-rs

Clarify catch_unwind behavior of RemoteHandle.

 use { /// The handle to a remote future returned by /// [`remote_handle`](crate::future::FutureExt::remote_handle). When you drop this, /// the remote future will be woken up to be dropped by the executor.+///+/// ## Unwind safety+///+/// When the remote future panics, [Remote] will catch the unwind and transfer it to+/// the thread where `RemoteHandle` is being awaited. This is good for the common+/// case where [Remote] is spawned on a threadpool. It is unlikely that other code+/// in the executor working thread shares mutable data with the spawned future and we+/// preserve the executor from losing it's working threads.

nit: its

najamelan

comment created time in 14 days

pull request commentrust-lang/rust

Backtrace Debug tweaks

This looks like a good improvement to me, thanks!

@bors r+

dtolnay

comment created time in 14 days

Pull request review commentrust-lang/futures-rs

Misc docs fixes

 pub trait StreamExt: Stream {         Flatten::new(self)     } -    /// Combinator similar to [`StreamExt::fold`] that holds internal state and produces a new stream.+    /// Combinator similar to [`StreamExt::fold`] that holds internal state +    /// and produces a new stream.     ///-    /// Accepts initial state and closure which will be applied to each element of the stream until provided closure-    /// returns `None`. Once `None` is returned, stream will be terminated.+    /// Accepts initial state and closure which will be applied to each element+    /// of the stream until provided closure returns `None`. Once `None` is+    /// returned, stream will be terminated. Because of current HRTB limitations,

and same elsewhere

olegnn

comment created time in 15 days

Pull request review commentrust-lang/futures-rs

Misc docs fixes

 pub trait StreamExt: Stream {         Flatten::new(self)     } -    /// Combinator similar to [`StreamExt::fold`] that holds internal state and produces a new stream.+    /// Combinator similar to [`StreamExt::fold`] that holds internal state +    /// and produces a new stream.     ///-    /// Accepts initial state and closure which will be applied to each element of the stream until provided closure-    /// returns `None`. Once `None` is returned, stream will be terminated.+    /// Accepts initial state and closure which will be applied to each element+    /// of the stream until provided closure returns `None`. Once `None` is+    /// returned, stream will be terminated. Because of current HRTB limitations,

Same here-- I don't think this should be added.

olegnn

comment created time in 15 days

Pull request review commentrust-lang/futures-rs

Misc docs fixes

 pub trait StreamExt: Stream {     ///     /// Note that this function consumes the stream passed into it and returns a     /// wrapped version of it, similar to the existing `filter` methods in the-    /// standard library.+    /// standard library. Because of current HRTB limitations, reference to item

I don't think this should be added-- I think it will confuse users more than help them.

olegnn

comment created time in 15 days

Pull request review commentrust-lang/futures-rs

Misc docs fixes

 pub trait AsyncReadExt: AsyncRead {     /// use futures::io::{self, AsyncReadExt, Cursor};     ///     /// // Note that for `Cursor` the read and write halves share a single-    /// // seek position. This may or may not be true for other types that+    /// // seek position. This may or may not be `true` for other types that

This isn't referring to true the value in the language, but the truth of a statement (whether read and write halves share a single seek position).

olegnn

comment created time in 15 days

push eventrust-lang/futures-rs

Naja Melan

commit sha c743c536f2e25a94f26bfe3212e735ea611e57a2

Add thread-pool feature for doc tests.

view details

push time in 15 days

PR merged rust-lang/futures-rs

Add thread-pool feature for doc tests.

The doc tests for futures-util require ThreadPool which is now behind a feature flag.

+1 -1

1 comment

1 changed file

najamelan

pr closed time in 15 days

pull request commentrust-lang/futures-rs

Add thread-pool feature for doc tests.

Thanks!

najamelan

comment created time in 15 days

push eventrust-lang/futures-rs

Naja Melan

commit sha 75c7b46c7b1cebe7b6c54017ed4e56256e3b950f

Document AsyncWrite (#1926) * AsyncWrite docs: fix copy paste error. * AsyncWrite docs: Add some implementation advice to `poll_write`. * AsyncWrite docs: Add some advice on implementing `poll_flush`.

view details

push time in 15 days

pull request commentrust-lang/futures-rs

Document AsyncWrite

Thanks!

najamelan

comment created time in 15 days

PR merged rust-lang/futures-rs

Document AsyncWrite

When implementing AsyncWrite I found it unclear what behavior is expected from a type that implements it. The main question is when to flush the underlying object.

This PR is intended to settle on that issue and then document it to avoid confusion for further users. It follows up from #1828. Some further discussion is required to come to a conclusion before documenting.

Explanation

Imagine we implement AsyncWrite on some type that does some internal buffering. Eg. this type will have data hanging in transit unless we call poll_flush on it.

The questions occurred when using AsyncReadExt::copy_buf_into to create an echo server that just forwards all incoming data back out. The future returned by this method will only flush the AsyncWrite when the stream has completely ended. Until then, it will only call poll_write. So if some data comes in, then there is a pause, this data will now just sit in the writer without getting flushed out.

The question is thus, should implementers sometimes flush in poll_write or not? If so, which context to pass to poll_flush? If any bytes have been written, poll_write needs to return Poll::Ready(n), so a Pending from the poll_flush cannot be bubbled up unless no bytes where written...

+6 -1

0 comment

1 changed file

najamelan

pr closed time in 15 days

Pull request review commentrust-lang/futures-rs

Add `StreamExt::flat_map`

 pub trait StreamExt: Stream {     /// Maps a stream like [`StreamExt::map`] but flattens nested `Stream`s.     ///     /// [`StreamExt::map`] is very useful, but if it produces a `Stream` instead,-    /// there's an extra layer of indirection. `flat_map()` will remove this extra-    /// layer on its own.+    /// you should chain cominators like `.map(f).flatten()` while this combinator

you should

"you would have to"?

olegnn

comment created time in 15 days

Pull request review commentrust-lang/futures-rs

Add `StreamExt::flat_map`

 pub trait StreamExt: Stream {         Flatten::new(self)     } +    /// Maps a stream like [`StreamExt::map`] but flattens nested `Stream`s.+    ///+    /// [`StreamExt::map`] is very useful, but if it produces a `Stream` instead,

Absolutely-- I want it all the time, and opened https://github.com/rust-lang/futures-rs/issues/1781 for this. Unfortunately it's somewhat complicated to implement efficiently, and would require something similar to FuturesUnordered for streams.

olegnn

comment created time in 15 days

Pull request review commentrust-lang/futures-rs

Document AsyncWrite

 mod if_std {         /// `Interrupted`.  Implementations must convert `WouldBlock` into         /// `Poll::Pending` and either internally retry or convert         /// `Interrupted` into another error kind.+        ///+        /// It only makes sense to do anything here if you actually buffer data. Otherwise,

I'm not sure this paragraph is helpful beyond perhaps the first sentence.

najamelan

comment created time in 15 days

Pull request review commentrust-lang/futures-rs

Add `StreamExt::flat_map`

 pub trait StreamExt: Stream {         Flatten::new(self)     } +    /// Maps a stream like [`StreamExt::map`] but flattens nested `Stream`s.+    ///+    /// [`StreamExt::map`] is very useful, but if it produces a `Stream` instead,

I'd rephrase this to avoid talking about "extra layers"-- perhaps refer to.map(...).flatten()`? Also, consider mentioning that this combinator will yield all items from the first stream before coming back and pulling out another stream, so it's not suitable for handling values from multiple streams concurrently.

olegnn

comment created time in 16 days

Pull request review commentrust-lang/futures-rs

Add `StreamExt::flat_map`

+use super::Map;+use core::fmt;+use core::pin::Pin;+use futures_core::stream::{FusedStream, Stream};+use futures_core::task::{Context, Poll};+#[cfg(feature = "sink")]+use futures_sink::Sink;+use pin_utils::unsafe_pinned;++/// Stream for the [`flat_map`](super::StreamExt::flat_map) method.+#[must_use = "streams do nothing unless polled"]+pub struct FlatMap<St, U, F> {+    stream: Map<St, F>,+    inner_stream: Option<U>,+}++impl<St: Unpin, U, F> Unpin for FlatMap<St, U, F> {}

This impl needs to also be conditional on U: Unpin

olegnn

comment created time in 16 days

push eventrust-lang/futures-rs

Diggory Blake

commit sha db04a7e8092025c6602266e6a03f09b488f6a56e

Implement fast-path for already-completed shared futures

view details

push time in 16 days

issue closedrust-lang/futures-rs

FutureExt::shared() could take fewer locks

I ran into this because I wanted to create a client for a simple network protocol. The problem is that it takes time for the connection to the server to be established, but I want to hide that from users, eg.

struct Client {
    connection: Shared<ConnectionFuture>,
}
impl Client {
    fn new() -> Self {
        Self { connection: connect_async().shared() }
    }
    async fn call(&self, msg: Input) -> Output {
        let connection = self.connection.clone().await;
        connection.call(msg).await
    }
}

However, polling the Shared future on every call is expensive even after the inner future completes because it takes a lock on every call. It would be more efficient if it simply remembered that it had completed already.

I implemented a similar function to shared() that gives out references instead of Arcs here and I was able to incorporate this optimization by checking for completion before doing anything else.

By inserting a check before this line the wakers mutex need not be taken, and the future can immediately return Ready(..)

closed time in 16 days

Diggsey

pull request commentrust-lang/futures-rs

Document unfairness in futures-aware mutex

Thanks!

Diggsey

comment created time in 16 days

push eventrust-lang/futures-rs

Diggory Blake

commit sha bd46631f7456d9677d799c6fb54e872f302b1e8e

Document unfairness in futures-aware mutex

view details

push time in 16 days

issue commentrust-lang/futures-rs

`Stream::flatten_unordered` would be nice

Yes, that's what I'm describing.

cramertj

comment created time in 16 days

issue commentrust-lang/futures-rs

`Stream::flatten_unordered` would be nice

No-- this would flatten a stream of streams, rather than just combining two streams.

cramertj

comment created time in 16 days

Pull request review commentrust-lang/futures-rs

Document AsyncWrite

 mod if_std {         /// `Interrupted`.  Implementations must convert `WouldBlock` into         /// `Poll::Pending` and either internally retry or convert         /// `Interrupted` into another error kind.+        ///+        /// `poll_write` must try to make progress by flushing the underlying object before returning

The example that you wrote in the codeblock above sounds reasonable to me!

najamelan

comment created time in 16 days

pull request commentrust-lang/rust

Pretty-print generic params and where clauses on associated types

Looks great to me, thanks!

@bors r+

Areredify

comment created time in 20 days

created tagrust-lang/futures-rs

tag0.3.4

Zero-cost asynchronous programming in Rust

created time in 21 days

release rust-lang/futures-rs

0.3.4

released time in 21 days

pull request commentrust-lang/rust

Pretty-print generic params and where clauses on associated types

Can you add a regression test so we can be sure this stays fixed?

Areredify

comment created time in 21 days

delete branch cramertj/futures-rs

delete branch : 0.3.4

delete time in 21 days

push eventrust-lang/futures-rs

Taylor Cramer

commit sha 771513cea996bac0c8c4017be687e289c966f504

Stage 0.3.4

view details

push time in 21 days

PR merged rust-lang/futures-rs

Stage 0.3.4
+47 -44

0 comment

12 changed files

cramertj

pr closed time in 21 days

PR opened rust-lang/futures-rs

Stage 0.3.4
+47 -44

0 comment

12 changed files

pr created time in 21 days

create barnchcramertj/futures-rs

branch : 0.3.4

created branch time in 21 days

push eventrust-lang/futures-rs

Adam Lesinski

commit sha 6e81b1e8a0a42b1bc5d90acd350295bb6789ebd3

Fix cargo clippy error Fixes a redundant import error.

view details

push time in 21 days

PR merged rust-lang/futures-rs

Fix cargo clippy error

Fixes a redundant import error.

+0 -1

0 comment

1 changed file

adamlesinski

pr closed time in 21 days

push eventrust-lang/futures-rs

Adam Lesinski

commit sha 79795438c21ace4937a3c08c004c8ebf74e94018

Add Drop impl to futures::channel::mpsc::UnboundedReceiver Pre-0.3.2, clients could expect to drop an UnboundedReceiver and observe that incoming messages are dropped and the channel closed. This change re-introduces this behavior for UnboundedReceiver and adds tests to prevent regressions. Note that a drop impl already exists for BoundedReceiver.

view details

push time in 22 days

PR merged rust-lang/futures-rs

Add Drop impl to futures::channel::mpsc::UnboundedReceiver

Pre-0.3.2, clients could expect to drop an UnboundedReceiver and observe that incoming messages are dropped and the channel closed.

This change re-introduces this behavior for UnboundedReceiver and adds tests to prevent regressions.

Note that a drop impl already exists for BoundedReceiver.

+55 -0

2 comments

2 changed files

adamlesinski

pr closed time in 22 days

pull request commentrust-lang/futures-rs

Add Drop impl to futures::channel::mpsc::UnboundedReceiver

Seems good to me to continue to match the behavior of BoundedReceiver.

adamlesinski

comment created time in 22 days

created tagrust-lang/futures-rs

tag0.3.3

Zero-cost asynchronous programming in Rust

created time in 23 days

release rust-lang/futures-rs

0.3.3

released time in 23 days

delete branch cramertj/futures-rs

delete branch : 0.3.3

delete time in 23 days

push eventrust-lang/futures-rs

Taylor Cramer

commit sha 09d7001b269f8f84c4e5501eed859d841ed84e2d

Stage 0.3.3

view details

push time in 23 days

PR merged rust-lang/futures-rs

Stage 0.3.3

r? @Nemo157

+47 -44

0 comment

12 changed files

cramertj

pr closed time in 23 days

pull request commentrust-lang/rust

[wip] degenerate object safety check for crater

People definitely use TryStream quite a bit. TryStream<Ok = A, Error = B> would ideally be just an alias for Stream<Item = Result<A, B>>, but unfortunately it is not today.

nikomatsakis

comment created time in 23 days

PR opened rust-lang/futures-rs

Stage 0.3.3

r? @Nemo157

+47 -44

0 comment

12 changed files

pr created time in 23 days

create barnchcramertj/futures-rs

branch : 0.3.3

created branch time in 23 days

push eventrust-lang/futures-rs

Wim Looman

commit sha 5c13a654cfa1b551330ca6c5e471c1fe3c047cf3

Fix compatibility of futures-util with futures 0.3.1

view details

push time in 23 days

PR merged rust-lang/futures-rs

Fix compatibility of futures-util with futures 0.3.1

Fixes the compilation error noted in #2061. Tested by locally patching futures 0.3.1 to use a path dependency on this futures-util and checking it built.

+7 -2

0 comment

1 changed file

Nemo157

pr closed time in 23 days

issue commentrust-lang/futures-rs

error: expected item after attributes using Rust 1.41

Sure, I'll publish 0.3.3 once #2062 is in. In general, though, using old futures facades with new versions of futures-util is a pretty odd usecase that we won't be testing against, and I'd advise against pinning the futures facade without pinning the inner crates-- I can't think of any reason why you'd want that behavior.

galich

comment created time in 23 days

created tagrust-lang/futures-rs

tag0.3.2

Zero-cost asynchronous programming in Rust

created time in 24 days

release rust-lang/futures-rs

0.3.2

released time in 24 days

delete branch cramertj/futures-rs

delete branch : 0.3.2

delete time in 24 days

push eventrust-lang/futures-rs

Taylor Cramer

commit sha b825f307944660c31b99cb39abbedf84528f6369

Stage 0.3.2

view details

push time in 24 days

PR merged rust-lang/futures-rs

Stage 0.3.2
+60 -45

0 comment

12 changed files

cramertj

pr closed time in 24 days

PR opened rust-lang/futures-rs

Stage 0.3.2
+60 -45

0 comment

12 changed files

pr created time in 24 days

create barnchcramertj/futures-rs

branch : 0.3.2

created branch time in 24 days

push eventrust-lang/futures-rs

Jacob Kiesel

commit sha d7f2530c2fff79c2c4ef1e023fdf831dd2fabbc7

Add TryFutureExt::map_ok_or_else method

view details

Jacob Kiesel

commit sha 3e936bcd5bd12ec026fb70a6c50f72b22eb6f334

Fix doc link

view details

Jacob Kiesel

commit sha 1329276354e622f7860e3ec1ef49035ae02365da

Fix is_terminated

view details

push time in 24 days

PR merged rust-lang/futures-rs

Add TryFutureExt::map_ok_or_else method

Similar to the recently stabilized Result::map_or_else method, this adds a method to the TryFutureExt trait that fulfills a similar purpose.

+104 -0

1 comment

2 changed files

Xaeroxe

pr closed time in 24 days

pull request commentrust-lang/futures-rs

Add TryFutureExt::map_ok_or_else method

Thanks!

Xaeroxe

comment created time in 24 days

Pull request review commentrust-lang/futures-rs

Add TryFutureExt::map_ok_or_else method

+use core::pin::Pin;+use futures_core::future::{FusedFuture, Future, TryFuture};+use futures_core::task::{Context, Poll};+use pin_utils::{unsafe_pinned, unsafe_unpinned};++/// Future for the [`map_ok_or_else`](super::TryFutureExt::map_ok_or_else) method.+#[derive(Debug)]+#[must_use = "futures do nothing unless you `.await` or poll them"]+pub struct MapOkOrElse<Fut, F, E> {+    future: Fut,+    f: Option<F>,+    e: Option<E>,+}++impl<Fut, F, E> MapOkOrElse<Fut, F, E> {+    unsafe_pinned!(future: Fut);+    unsafe_unpinned!(f: Option<F>);+    unsafe_unpinned!(e: Option<E>);++    /// Creates a new MapOkOrElse.+    pub(super) fn new(future: Fut, e: E, f: F) -> Self {+        Self { future, f: Some(f), e: Some(e) }+    }+}++impl<Fut: Unpin, F, E> Unpin for MapOkOrElse<Fut, F, E> {}++impl<Fut, F, E, T> FusedFuture for MapOkOrElse<Fut, F, E>+    where Fut: TryFuture,+          F: FnOnce(Fut::Ok) -> T,+          E: FnOnce(Fut::Error) -> T,+{+    fn is_terminated(&self) -> bool {+        self.f.is_none()

This should be self.f.is_none() || self.e.is_none()

Xaeroxe

comment created time in 24 days

push eventrust-lang/async-book

Black3HDF

commit sha 15281c6a3d5143adce2feabf4e727044c86cf528

update dep

view details

push time in 24 days

more