Upgrade to Tokio v1

[Urhengulas]

Dependencies which need to upgrade

• hyper (feat(lib): Upgrade to Tokio 1.0 hyperium/hyper#2369)
• tokio-rustls (Update to tokio 1.0 tokio-rs/tls#46)
• tokio-tungstenite (Upgrade to tokio 1.0 snapview/tokio-tungstenite#142)

[seanmonstar]

Yep, needs to happen in hyper first: hyperium/hyper#2302

[Urhengulas]

Yep, needs to happen in hyper first: hyperium/hyper#2302

Yes, also saw that :)
The patch besides the hyper changes is quite small anyways.

bump-warp.patch

diff --git a/Cargo.toml b/Cargo.toml
index b40c2b5..89f681e 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -31,7 +31,7 @@ scoped-tls = "1.0"
 serde = "1.0"
 serde_json = "1.0"
 serde_urlencoded = "0.7"
-tokio = { version = "0.2", features = ["fs", "stream", "sync", "time"] }
+tokio = { version = "0.3", features = ["fs", "stream", "sync", "time"] }
 tracing = { version = "0.1", default-features = false, features = ["log", "std"] }
 tracing-futures = { version = "0.2", default-features = false, features = ["std-future"] }
 tower-service = "0.3"
@@ -47,7 +47,7 @@ tracing-subscriber = "0.2.7"
 tracing-log = "0.1"
 serde_derive = "1.0"
 handlebars = "3.0.0"
-tokio = { version = "0.2", features = ["macros"] }
+tokio = { version = "0.3", features = ["full"] }
 listenfd = "0.3"
 
 [features]
diff --git a/src/filters/fs.rs b/src/filters/fs.rs
index 1f04f6b..d4b9fc8 100644
--- a/src/filters/fs.rs
+++ b/src/filters/fs.rs
@@ -22,7 +22,6 @@ use hyper::Body;
 use mime_guess;
 use percent_encoding::percent_decode_str;
 use tokio::fs::File as TkFile;
-use tokio::io::AsyncRead;
 
 use crate::filter::{Filter, FilterClone, One};
 use crate::reject::{self, Rejection};
diff --git a/src/filters/sse.rs b/src/filters/sse.rs
index 8c4eda5..9d58492 100644
--- a/src/filters/sse.rs
+++ b/src/filters/sse.rs
@@ -54,7 +54,7 @@ use hyper::Body;
 use pin_project::pin_project;
 use serde::Serialize;
 use serde_json;
-use tokio::time::{self, Delay};
+use tokio::time::{self, Sleep};
 
 use self::sealed::{
     BoxedServerSentEvent, EitherServerSentEvent, SseError, SseField, SseFormat, SseWrapper,
@@ -467,7 +467,7 @@ impl KeepAlive {
         S::Ok: ServerSentEvent + Send,
         S::Error: StdError + Send + Sync + 'static,
     {
-        let alive_timer = time::delay_for(self.max_interval);
+        let alive_timer = time::sleep(self.max_interval);
         SseKeepAlive {
             event_stream,
             comment_text: self.comment_text,
@@ -484,7 +484,7 @@ struct SseKeepAlive<S> {
     event_stream: S,
     comment_text: Cow<'static, str>,
     max_interval: Duration,
-    alive_timer: Delay,
+    alive_timer: Sleep,
 }
 
 #[doc(hidden)]
@@ -505,7 +505,7 @@ where
     let max_interval = keep_interval
         .into()
         .unwrap_or_else(|| Duration::from_secs(15));
-    let alive_timer = time::delay_for(max_interval);
+    let alive_timer = time::sleep(max_interval);
     SseKeepAlive {
         event_stream,
         comment_text: Cow::Borrowed(""),

[jxs]

there's also the dependency on tokio-tungstenite and tokio-rustls.
tokio-rustls already has a PR upgrading it: tokio-rs/tls#29

[pomazanbohdan]

seanmonstar/reqwest#1060

[vn971]

Note that currently, warp can start with tokio being explicitly set to 0.3, and it will then fail at run-time. I wonder if we can/should tackle this problem so that it doesn't affect us in the future? E.g. so that the same run-time error cannot appear in future tokio releases (if applicable).

I'm really happy to see that the problem is being addressed in all the referenced projects though, thanks a lot for keeping it up-to-date!

[Urhengulas]

Note that currently, warp can start with tokio being explicitly set to 0.3, and it will then fail at run-time. I wonder if we can/should tackle this problem so that it doesn't affect us in the future? E.g. so that the same run-time error cannot appear in future tokio releases (if applicable).

I'm really happy to see that the problem is being addressed in all the referenced projects though, thanks a lot for keeping it up-to-date!

@vn971 That is a very good idea. I had this problem in my project, that I thought I successfully upgraded to tokio 0.3, but then it actually failed on runtime, since dependencies are using tokio 0.2.

What would be an approach to avoid that for the future? Let tokio check the dependency tree on compile-time?