Tokio released 1.17 which requires mio 0.8 causing a SemVer breaking change for quinn-udp

[ecton]

See tokio-rs/tokio#4512 for the report to Tokio about this change.

quinn-udp specifies a requirement on tokio 1.0.1 and mio 0.7. tokio 1.17 depends on mio 0.8, causing a version incompatibility that happens at runtime:

thread 'tokio-runtime-worker' panicked at 'mio must be compiled with `os-poll` to run.', /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.7.14/src/sys/shell/udp.rs:9:5
stack backtrace:
thread 'tokio-runtime-worker' panicked at 'mio must be compiled with `os-poll` to run.', /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.7.14/src/sys/shell/udp.rs:9:5
Received Pong from server on websockets
   0: std::panicking::begin_panic
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:525:12
   1: mio::sys::shell::udp::only_v6
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.7.14/src/sys/shell/udp.rs:9:5
   2: mio::net::udp::UdpSocket::only_v6
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.7.14/src/net/udp.rs:517:9
   3: quinn_udp::imp::init
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/quinn-udp-0.1.0/src/unix.rs:103:84
   4: quinn_udp::imp::UdpSocket::from_std
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/quinn-udp-0.1.0/src/unix.rs:38:9
   5: quinn::endpoint::Endpoint::new
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/quinn-0.8.0/src/endpoint.rs:83:22
   6: quinn::endpoint::Endpoint::server
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/quinn-0.8.0/src/endpoint.rs:71:9
   7: fabruic::quic::endpoint::Endpoint::new
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/fabruic-0.0.1-dev.5/src/quic/endpoint/mod.rs:93:32

I'm going to work around this myself by pinning tokio to 1.16.1 in my library and releasing new updates.

[djc]

Thanks for reporting! Let's see what the tokio folks say.

[Darksonn]

Sorry, we probably aren't going to fix this on Tokio's end. Avoiding this kind of breakage is not really possible unless we decide to never upgrade any of our dependencies, including the private ones. You can fix it by adding os-poll to the list of features you require from mio.

[djc]

Yeah, this is our fault for not explicitly depending on the os-poll feature, I suppose. @ecton want to submit a PR for that?

[ecton]

Yep, was just going to clone the repo and try it out. I'll have a PR in soon.