1#![allow(
2 clippy::cognitive_complexity,
3 clippy::large_enum_variant,
4 clippy::module_inception,
5 clippy::needless_doctest_main,
6 clippy::declare_interior_mutable_const
7)]
8#![warn(
9 missing_debug_implementations,
10 missing_docs,
11 rust_2018_idioms,
12 unreachable_pub
13)]
14#![deny(unused_must_use)]
15#![doc(test(
16 no_crate_inject,
17 attr(deny(warnings, rust_2018_idioms), allow(dead_code, unused_variables))
18))]
19#![cfg_attr(docsrs, feature(doc_cfg))]
20#![cfg_attr(docsrs, allow(unused_attributes))]
21#![cfg_attr(loom, allow(dead_code, unreachable_pub))]
22
23//! A runtime for writing reliable network applications without compromising speed.
24//!
25//! Tokio is an event-driven, non-blocking I/O platform for writing asynchronous
26//! applications with the Rust programming language. At a high level, it
27//! provides a few major components:
28//!
29//! * Tools for [working with asynchronous tasks][tasks], including
30//! [synchronization primitives and channels][sync] and [timeouts, sleeps, and
31//! intervals][time].
32//! * APIs for [performing asynchronous I/O][io], including [TCP and UDP][net] sockets,
33//! [filesystem][fs] operations, and [process] and [signal] management.
34//! * A [runtime] for executing asynchronous code, including a task scheduler,
35//! an I/O driver backed by the operating system's event queue (epoll, kqueue,
36//! IOCP, etc...), and a high performance timer.
37//!
38//! Guide level documentation is found on the [website].
39//!
40//! [tasks]: #working-with-tasks
41//! [sync]: crate::sync
42//! [time]: crate::time
43//! [io]: #asynchronous-io
44//! [net]: crate::net
45//! [fs]: crate::fs
46//! [process]: crate::process
47//! [signal]: crate::signal
48//! [fs]: crate::fs
49//! [runtime]: crate::runtime
50//! [website]: https://tokio.rs/tokio/tutorial
51//!
52//! # A Tour of Tokio
53//!
54//! Tokio consists of a number of modules that provide a range of functionality
55//! essential for implementing asynchronous applications in Rust. In this
56//! section, we will take a brief tour of Tokio, summarizing the major APIs and
57//! their uses.
58//!
59//! The easiest way to get started is to enable all features. Do this by
60//! enabling the `full` feature flag:
61//!
62//! ```toml
63//! tokio = { version = "1", features = ["full"] }
64//! ```
65//!
66//! ### Authoring applications
67//!
68//! Tokio is great for writing applications and most users in this case shouldn't
69//! worry too much about what features they should pick. If you're unsure, we suggest
70//! going with `full` to ensure that you don't run into any road blocks while you're
71//! building your application.
72//!
73//! #### Example
74//!
75//! This example shows the quickest way to get started with Tokio.
76//!
77//! ```toml
78//! tokio = { version = "1", features = ["full"] }
79//! ```
80//!
81//! ### Authoring libraries
82//!
83//! As a library author your goal should be to provide the lightest weight crate
84//! that is based on Tokio. To achieve this you should ensure that you only enable
85//! the features you need. This allows users to pick up your crate without having
86//! to enable unnecessary features.
87//!
88//! #### Example
89//!
90//! This example shows how you may want to import features for a library that just
91//! needs to `tokio::spawn` and use a `TcpStream`.
92//!
93//! ```toml
94//! tokio = { version = "1", features = ["rt", "net"] }
95//! ```
96//!
97//! ## Working With Tasks
98//!
99//! Asynchronous programs in Rust are based around lightweight, non-blocking
100//! units of execution called [_tasks_][tasks]. The [`tokio::task`] module provides
101//! important tools for working with tasks:
102//!
103//! * The [`spawn`] function and [`JoinHandle`] type, for scheduling a new task
104//! on the Tokio runtime and awaiting the output of a spawned task, respectively,
105//! * Functions for [running blocking operations][blocking] in an asynchronous
106//! task context.
107//!
108//! The [`tokio::task`] module is present only when the "rt" feature flag
109//! is enabled.
110//!
111//! [tasks]: task/index.html#what-are-tasks
112//! [`tokio::task`]: crate::task
113//! [`spawn`]: crate::task::spawn()
114//! [`JoinHandle`]: crate::task::JoinHandle
115//! [blocking]: task/index.html#blocking-and-yielding
116//!
117//! The [`tokio::sync`] module contains synchronization primitives to use when
118//! needing to communicate or share data. These include:
119//!
120//! * channels ([`oneshot`], [`mpsc`], [`watch`], and [`broadcast`]), for sending values
121//! between tasks,
122//! * a non-blocking [`Mutex`], for controlling access to a shared, mutable
123//! value,
124//! * an asynchronous [`Barrier`] type, for multiple tasks to synchronize before
125//! beginning a computation.
126//!
127//! The `tokio::sync` module is present only when the "sync" feature flag is
128//! enabled.
129//!
130//! [`tokio::sync`]: crate::sync
131//! [`Mutex`]: crate::sync::Mutex
132//! [`Barrier`]: crate::sync::Barrier
133//! [`oneshot`]: crate::sync::oneshot
134//! [`mpsc`]: crate::sync::mpsc
135//! [`watch`]: crate::sync::watch
136//! [`broadcast`]: crate::sync::broadcast
137//!
138//! The [`tokio::time`] module provides utilities for tracking time and
139//! scheduling work. This includes functions for setting [timeouts][timeout] for
140//! tasks, [sleeping][sleep] work to run in the future, or [repeating an operation at an
141//! interval][interval].
142//!
143//! In order to use `tokio::time`, the "time" feature flag must be enabled.
144//!
145//! [`tokio::time`]: crate::time
146//! [sleep]: crate::time::sleep()
147//! [interval]: crate::time::interval()
148//! [timeout]: crate::time::timeout()
149//!
150//! Finally, Tokio provides a _runtime_ for executing asynchronous tasks. Most
151//! applications can use the [`#[tokio::main]`][main] macro to run their code on the
152//! Tokio runtime. However, this macro provides only basic configuration options. As
153//! an alternative, the [`tokio::runtime`] module provides more powerful APIs for configuring
154//! and managing runtimes. You should use that module if the `#[tokio::main]` macro doesn't
155//! provide the functionality you need.
156//!
157//! Using the runtime requires the "rt" or "rt-multi-thread" feature flags, to
158//! enable the current-thread [single-threaded scheduler][rt] and the [multi-thread
159//! scheduler][rt-multi-thread], respectively. See the [`runtime` module
160//! documentation][rt-features] for details. In addition, the "macros" feature
161//! flag enables the `#[tokio::main]` and `#[tokio::test]` attributes.
162//!
163//! [main]: attr.main.html
164//! [`tokio::runtime`]: crate::runtime
165//! [`Builder`]: crate::runtime::Builder
166//! [`Runtime`]: crate::runtime::Runtime
167//! [rt]: runtime/index.html#current-thread-scheduler
168//! [rt-multi-thread]: runtime/index.html#multi-thread-scheduler
169//! [rt-features]: runtime/index.html#runtime-scheduler
170//!
171//! ## CPU-bound tasks and blocking code
172//!
173//! Tokio is able to concurrently run many tasks on a few threads by repeatedly
174//! swapping the currently running task on each thread. However, this kind of
175//! swapping can only happen at `.await` points, so code that spends a long time
176//! without reaching an `.await` will prevent other tasks from running. To
177//! combat this, Tokio provides two kinds of threads: Core threads and blocking threads.
178//!
179//! The core threads are where all asynchronous code runs, and Tokio will by default
180//! spawn one for each CPU core. You can use the environment variable `TOKIO_WORKER_THREADS`
181//! to override the default value.
182//!
183//! The blocking threads are spawned on demand, can be used to run blocking code
184//! that would otherwise block other tasks from running and are kept alive when
185//! not used for a certain amount of time which can be configured with [`thread_keep_alive`].
186//! Since it is not possible for Tokio to swap out blocking tasks, like it
187//! can do with asynchronous code, the upper limit on the number of blocking
188//! threads is very large. These limits can be configured on the [`Builder`].
189//!
190//! To spawn a blocking task, you should use the [`spawn_blocking`] function.
191//!
192//! [`Builder`]: crate::runtime::Builder
193//! [`spawn_blocking`]: crate::task::spawn_blocking()
194//! [`thread_keep_alive`]: crate::runtime::Builder::thread_keep_alive()
195//!
196//! ```
197//! #[tokio::main]
198//! async fn main() {
199//! // This is running on a core thread.
200//!
201//! let blocking_task = tokio::task::spawn_blocking(|| {
202//! // This is running on a blocking thread.
203//! // Blocking here is ok.
204//! });
205//!
206//! // We can wait for the blocking task like this:
207//! // If the blocking task panics, the unwrap below will propagate the
208//! // panic.
209//! blocking_task.await.unwrap();
210//! }
211//! ```
212//!
213//! If your code is CPU-bound and you wish to limit the number of threads used
214//! to run it, you should use a separate thread pool dedicated to CPU bound tasks.
215//! For example, you could consider using the [rayon] library for CPU-bound
216//! tasks. It is also possible to create an extra Tokio runtime dedicated to
217//! CPU-bound tasks, but if you do this, you should be careful that the extra
218//! runtime runs _only_ CPU-bound tasks, as IO-bound tasks on that runtime
219//! will behave poorly.
220//!
221//! Hint: If using rayon, you can use a [`oneshot`] channel to send the result back
222//! to Tokio when the rayon task finishes.
223//!
224//! [rayon]: https://docs.rs/rayon
225//! [`oneshot`]: crate::sync::oneshot
226//!
227//! ## Asynchronous IO
228//!
229//! As well as scheduling and running tasks, Tokio provides everything you need
230//! to perform input and output asynchronously.
231//!
232//! The [`tokio::io`] module provides Tokio's asynchronous core I/O primitives,
233//! the [`AsyncRead`], [`AsyncWrite`], and [`AsyncBufRead`] traits. In addition,
234//! when the "io-util" feature flag is enabled, it also provides combinators and
235//! functions for working with these traits, forming as an asynchronous
236//! counterpart to [`std::io`].
237//!
238//! Tokio also includes APIs for performing various kinds of I/O and interacting
239//! with the operating system asynchronously. These include:
240//!
241//! * [`tokio::net`], which contains non-blocking versions of [TCP], [UDP], and
242//! [Unix Domain Sockets][UDS] (enabled by the "net" feature flag),
243//! * [`tokio::fs`], similar to [`std::fs`] but for performing filesystem I/O
244//! asynchronously (enabled by the "fs" feature flag),
245//! * [`tokio::signal`], for asynchronously handling Unix and Windows OS signals
246//! (enabled by the "signal" feature flag),
247//! * [`tokio::process`], for spawning and managing child processes (enabled by
248//! the "process" feature flag).
249//!
250//! [`tokio::io`]: crate::io
251//! [`AsyncRead`]: crate::io::AsyncRead
252//! [`AsyncWrite`]: crate::io::AsyncWrite
253//! [`AsyncBufRead`]: crate::io::AsyncBufRead
254//! [`std::io`]: std::io
255//! [`tokio::net`]: crate::net
256//! [TCP]: crate::net::tcp
257//! [UDP]: crate::net::UdpSocket
258//! [UDS]: crate::net::unix
259//! [`tokio::fs`]: crate::fs
260//! [`std::fs`]: std::fs
261//! [`tokio::signal`]: crate::signal
262//! [`tokio::process`]: crate::process
263//!
264//! # Examples
265//!
266//! A simple TCP echo server:
267//!
268//! ```no_run
269//! use tokio::net::TcpListener;
270//! use tokio::io::{AsyncReadExt, AsyncWriteExt};
271//!
272//! #[tokio::main]
273//! async fn main() -> Result<(), Box<dyn std::error::Error>> {
274//! let listener = TcpListener::bind("127.0.0.1:8080").await?;
275//!
276//! loop {
277//! let (mut socket, _) = listener.accept().await?;
278//!
279//! tokio::spawn(async move {
280//! let mut buf = [0; 1024];
281//!
282//! // In a loop, read data from the socket and write the data back.
283//! loop {
284//! let n = match socket.read(&mut buf).await {
285//! // socket closed
286//! Ok(n) if n == 0 => return,
287//! Ok(n) => n,
288//! Err(e) => {
289//! eprintln!("failed to read from socket; err = {:?}", e);
290//! return;
291//! }
292//! };
293//!
294//! // Write the data back
295//! if let Err(e) = socket.write_all(&buf[0..n]).await {
296//! eprintln!("failed to write to socket; err = {:?}", e);
297//! return;
298//! }
299//! }
300//! });
301//! }
302//! }
303//! ```
304//!
305//! ## Feature flags
306//!
307//! Tokio uses a set of [feature flags] to reduce the amount of compiled code. It
308//! is possible to just enable certain features over others. By default, Tokio
309//! does not enable any features but allows one to enable a subset for their use
310//! case. Below is a list of the available feature flags. You may also notice
311//! above each function, struct and trait there is listed one or more feature flags
312//! that are required for that item to be used. If you are new to Tokio it is
313//! recommended that you use the `full` feature flag which will enable all public APIs.
314//! Beware though that this will pull in many extra dependencies that you may not
315//! need.
316//!
317//! - `full`: Enables all features listed below except `test-util` and `tracing`.
318//! - `rt`: Enables `tokio::spawn`, the current-thread scheduler,
319//! and non-scheduler utilities.
320//! - `rt-multi-thread`: Enables the heavier, multi-threaded, work-stealing scheduler.
321//! - `io-util`: Enables the IO based `Ext` traits.
322//! - `io-std`: Enable `Stdout`, `Stdin` and `Stderr` types.
323//! - `net`: Enables `tokio::net` types such as `TcpStream`, `UnixStream` and
324//! `UdpSocket`, as well as (on Unix-like systems) `AsyncFd` and (on
325//! FreeBSD) `PollAio`.
326//! - `time`: Enables `tokio::time` types and allows the schedulers to enable
327//! the built in timer.
328//! - `process`: Enables `tokio::process` types.
329//! - `macros`: Enables `#[tokio::main]` and `#[tokio::test]` macros.
330//! - `sync`: Enables all `tokio::sync` types.
331//! - `signal`: Enables all `tokio::signal` types.
332//! - `fs`: Enables `tokio::fs` types.
333//! - `test-util`: Enables testing based infrastructure for the Tokio runtime.
334//! - `parking_lot`: As a potential optimization, use the _parking_lot_ crate's
335//! synchronization primitives internally. Also, this
336//! dependency is necessary to construct some of our primitives
337//! in a const context. MSRV may increase according to the
338//! _parking_lot_ release in use.
339//!
340//! _Note: `AsyncRead` and `AsyncWrite` traits do not require any features and are
341//! always available._
342//!
343//! ### Unstable features
344//!
345//! Some feature flags are only available when specifying the `tokio_unstable` flag:
346//!
347//! - `tracing`: Enables tracing events.
348//!
349//! Likewise, some parts of the API are only available with the same flag:
350//!
351//! - [`task::Builder`]
352//! - Some methods on [`task::JoinSet`]
353//! - [`runtime::RuntimeMetrics`]
354//! - [`runtime::Builder::unhandled_panic`]
355//! - [`task::Id`]
356//!
357//! This flag enables **unstable** features. The public API of these features
358//! may break in 1.x releases. To enable these features, the `--cfg
359//! tokio_unstable` argument must be passed to `rustc` when compiling. This
360//! serves to explicitly opt-in to features which may break semver conventions,
361//! since Cargo [does not yet directly support such opt-ins][unstable features].
362//!
363//! You can specify it in your project's `.cargo/config.toml` file:
364//!
365//! ```toml
366//! [build]
367//! rustflags = ["--cfg", "tokio_unstable"]
368//! ```
369//!
370//! Alternatively, you can specify it with an environment variable:
371//!
372//! ```sh
373//! ## Many *nix shells:
374//! export RUSTFLAGS="--cfg tokio_unstable"
375//! cargo build
376//! ```
377//!
378//! ```powershell
379//! ## Windows PowerShell:
380//! $Env:RUSTFLAGS="--cfg tokio_unstable"
381//! cargo build
382//! ```
383//!
384//! [unstable features]: https://internals.rust-lang.org/t/feature-request-unstable-opt-in-non-transitive-crate-features/16193#why-not-a-crate-feature-2
385//! [feature flags]: https://doc.rust-lang.org/cargo/reference/manifest.html#the-features-section
386//!
387//! ## Supported platforms
388//!
389//! Tokio currently guarantees support for the following platforms:
390//!
391//! * Linux
392//! * Windows
393//! * Android (API level 21)
394//! * macOS
395//! * iOS
396//! * FreeBSD
397//!
398//! Tokio will continue to support these platforms in the future. However,
399//! future releases may change requirements such as the minimum required libc
400//! version on Linux, the API level on Android, or the supported FreeBSD
401//! release.
402//!
403//! Beyond the above platforms, Tokio is intended to work on all platforms
404//! supported by the mio crate. You can find a longer list [in mio's
405//! documentation][mio-supported]. However, these additional platforms may
406//! become unsupported in the future.
407//!
408//! Note that Wine is considered to be a different platform from Windows. See
409//! mio's documentation for more information on Wine support.
410//!
411//! [mio-supported]: https://crates.io/crates/mio#platforms
412//!
413//! ### WASM support
414//!
415//! Tokio has some limited support for the WASM platform. Without the
416//! `tokio_unstable` flag, the following features are supported:
417//!
418//! * `sync`
419//! * `macros`
420//! * `io-util`
421//! * `rt`
422//! * `time`
423//!
424//! Enabling any other feature (including `full`) will cause a compilation
425//! failure.
426//!
427//! The `time` module will only work on WASM platforms that have support for
428//! timers (e.g. wasm32-wasi). The timing functions will panic if used on a WASM
429//! platform that does not support timers.
430//!
431//! Note also that if the runtime becomes indefinitely idle, it will panic
432//! immediately instead of blocking forever. On platforms that don't support
433//! time, this means that the runtime can never be idle in any way.
434//!
435//! ### Unstable WASM support
436//!
437//! Tokio also has unstable support for some additional WASM features. This
438//! requires the use of the `tokio_unstable` flag.
439//!
440//! Using this flag enables the use of `tokio::net` on the wasm32-wasi target.
441//! However, not all methods are available on the networking types as WASI
442//! currently does not support the creation of new sockets from within WASM.
443//! Because of this, sockets must currently be created via the `FromRawFd`
444//! trait.
445
446// Test that pointer width is compatible. This asserts that e.g. usize is at
447// least 32 bits, which a lot of components in Tokio currently assumes.
448//
449// TODO: improve once we have MSRV access to const eval to make more flexible.
450#[cfg(not(any(
451 target_pointer_width = "32",
452 target_pointer_width = "64",
453 target_pointer_width = "128"
454)))]
455compile_error! {
456 "Tokio requires the platform pointer width to be 32, 64, or 128 bits"
457}
458
459// Ensure that our build script has correctly set cfg flags for wasm.
460//
461// Each condition is written all(a, not(b)). This should be read as
462// "if a, then we must also have b".
463#[cfg(any(
464 all(target_arch = "wasm32", not(tokio_wasm)),
465 all(target_arch = "wasm64", not(tokio_wasm)),
466 all(target_family = "wasm", not(tokio_wasm)),
467 all(target_os = "wasi", not(tokio_wasm)),
468 all(target_os = "wasi", not(tokio_wasi)),
469 all(target_os = "wasi", tokio_wasm_not_wasi),
470 all(tokio_wasm, not(any(target_arch = "wasm32", target_arch = "wasm64"))),
471 all(tokio_wasm_not_wasi, not(tokio_wasm)),
472 all(tokio_wasi, not(tokio_wasm))
473))]
474compile_error!("Tokio's build script has incorrectly detected wasm.");
475
476#[cfg(all(
477 not(tokio_unstable),
478 tokio_wasm,
479 any(
480 feature = "fs",
481 feature = "io-std",
482 feature = "net",
483 feature = "process",
484 feature = "rt-multi-thread",
485 feature = "signal"
486 )
487))]
488compile_error!("Only features sync,macros,io-util,rt,time are supported on wasm.");
489
490#[cfg(all(not(tokio_unstable), tokio_taskdump))]
491compile_error!("The `tokio_taskdump` feature requires `--cfg tokio_unstable`.");
492
493#[cfg(all(
494 tokio_taskdump,
495 not(all(
496 target_os = "linux",
497 any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")
498 ))
499))]
500compile_error!(
501 "The `tokio_taskdump` feature is only currently supported on \
502linux, on `aarch64`, `x86` and `x86_64`."
503);
504
505// Includes re-exports used by macros.
506//
507// This module is not intended to be part of the public API. In general, any
508// `doc(hidden)` code is not part of Tokio's public and stable API.
509#[macro_use]
510#[doc(hidden)]
511pub mod macros;
512
513cfg_fs! {
514 pub mod fs;
515}
516
517mod future;
518
519pub mod io;
520pub mod net;
521
522mod loom;
523
524cfg_process! {
525 pub mod process;
526}
527
528#[cfg(any(
529 feature = "fs",
530 feature = "io-std",
531 feature = "net",
532 all(windows, feature = "process"),
533))]
534mod blocking;
535
536cfg_rt! {
537 pub mod runtime;
538}
539cfg_not_rt! {
540 pub(crate) mod runtime;
541}
542
543cfg_signal! {
544 pub mod signal;
545}
546
547cfg_signal_internal! {
548 #[cfg(not(feature = "signal"))]
549 #[allow(dead_code)]
550 #[allow(unreachable_pub)]
551 pub(crate) mod signal;
552}
553
554cfg_sync! {
555 pub mod sync;
556}
557cfg_not_sync! {
558 mod sync;
559}
560
561pub mod task;
562cfg_rt! {
563 pub use task::spawn;
564}
565
566cfg_time! {
567 pub mod time;
568}
569
570mod trace {
571 use std::future::Future;
572 use std::pin::Pin;
573 use std::task::{Context, Poll};
574
575 cfg_taskdump! {
576 pub(crate) use crate::runtime::task::trace::trace_leaf;
577 }
578
579 cfg_not_taskdump! {
580 #[inline(always)]
581 #[allow(dead_code)]
582 pub(crate) fn trace_leaf(_: &mut std::task::Context<'_>) -> std::task::Poll<()> {
583 std::task::Poll::Ready(())
584 }
585 }
586
587 #[cfg_attr(not(feature = "sync"), allow(dead_code))]
588 pub(crate) fn async_trace_leaf() -> impl Future<Output = ()> {
589 struct Trace;
590
591 impl Future for Trace {
592 type Output = ();
593
594 #[inline(always)]
595 fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
596 trace_leaf(cx)
597 }
598 }
599
600 Trace
601 }
602}
603
604mod util;
605
606/// Due to the `Stream` trait's inclusion in `std` landing later than Tokio's 1.0
607/// release, most of the Tokio stream utilities have been moved into the [`tokio-stream`]
608/// crate.
609///
610/// # Why was `Stream` not included in Tokio 1.0?
611///
612/// Originally, we had planned to ship Tokio 1.0 with a stable `Stream` type
613/// but unfortunately the [RFC] had not been merged in time for `Stream` to
614/// reach `std` on a stable compiler in time for the 1.0 release of Tokio. For
615/// this reason, the team has decided to move all `Stream` based utilities to
616/// the [`tokio-stream`] crate. While this is not ideal, once `Stream` has made
617/// it into the standard library and the MSRV period has passed, we will implement
618/// stream for our different types.
619///
620/// While this may seem unfortunate, not all is lost as you can get much of the
621/// `Stream` support with `async/await` and `while let` loops. It is also possible
622/// to create a `impl Stream` from `async fn` using the [`async-stream`] crate.
623///
624/// [`tokio-stream`]: https://docs.rs/tokio-stream
625/// [`async-stream`]: https://docs.rs/async-stream
626/// [RFC]: https://github.com/rust-lang/rfcs/pull/2996
627///
628/// # Example
629///
630/// Convert a [`sync::mpsc::Receiver`] to an `impl Stream`.
631///
632/// ```rust,no_run
633/// use tokio::sync::mpsc;
634///
635/// let (tx, mut rx) = mpsc::channel::<usize>(16);
636///
637/// let stream = async_stream::stream! {
638/// while let Some(item) = rx.recv().await {
639/// yield item;
640/// }
641/// };
642/// ```
643pub mod stream {}
644
645// local re-exports of platform specific things, allowing for decent
646// documentation to be shimmed in on docs.rs
647
648#[cfg(docsrs)]
649pub mod doc;
650
651#[cfg(docsrs)]
652#[allow(unused)]
653pub(crate) use self::doc::os;
654
655#[cfg(not(docsrs))]
656#[allow(unused)]
657pub(crate) use std::os;
658
659cfg_macros! {
660 /// Implementation detail of the `select!` macro. This macro is **not**
661 /// intended to be used as part of the public API and is permitted to
662 /// change.
663 #[doc(hidden)]
664 pub use tokio_macros::select_priv_declare_output_enum;
665
666 /// Implementation detail of the `select!` macro. This macro is **not**
667 /// intended to be used as part of the public API and is permitted to
668 /// change.
669 #[doc(hidden)]
670 pub use tokio_macros::select_priv_clean_pattern;
671
672 cfg_rt! {
673 #[cfg(feature = "rt-multi-thread")]
674 #[cfg(not(test))] // Work around for rust-lang/rust#62127
675 #[cfg_attr(docsrs, doc(cfg(feature = "macros")))]
676 #[doc(inline)]
677 pub use tokio_macros::main;
678
679 #[cfg(feature = "rt-multi-thread")]
680 #[cfg_attr(docsrs, doc(cfg(feature = "macros")))]
681 #[doc(inline)]
682 pub use tokio_macros::test;
683
684 cfg_not_rt_multi_thread! {
685 #[cfg(not(test))] // Work around for rust-lang/rust#62127
686 #[doc(inline)]
687 pub use tokio_macros::main_rt as main;
688
689 #[doc(inline)]
690 pub use tokio_macros::test_rt as test;
691 }
692 }
693
694 // Always fail if rt is not enabled.
695 cfg_not_rt! {
696 #[cfg(not(test))]
697 #[doc(inline)]
698 pub use tokio_macros::main_fail as main;
699
700 #[doc(inline)]
701 pub use tokio_macros::test_fail as test;
702 }
703}
704
705// TODO: rm
706#[cfg(feature = "io-util")]
707#[cfg(test)]
708fn is_unpin<T: Unpin>() {}
709
710/// fuzz test (fuzz_linked_list)
711#[cfg(fuzzing)]
712pub mod fuzz;
713