ci: unfreeze wasm tests from rustc 1.88.0

[lblack00]

Addresses failing wasm tests: #7519

Motivation

Currently, the MSRV is pinned temporarily and there is a large amount of failures for wasm doctests with the Rust 1.89.0 release.

Solution

Add ignore-wasm to failing doctests until these tests pass with the new release.

Apply flavor = current_thread to tokio::main macro to enable single-threaded execution on WASM tests.

Partially enable WASM tests using conditional compilation.

[ADD-SP]

Please also revert #7518 .

[lblack00]

These annotations are only for a small section of the failing wasm tests, which yields:
test result: FAILED. 93 passed; 265 failed; 20 ignored; 0 measured; 0 filtered out; finished in 3.91s

I plan on opening PRs for the remaining sections to it split up based on module, unless it is preferred to aggregate all annotations here

[mox692]

@lblack00

Thank you for the PR!

I plan on opening PRs for the remaining sections to it split up based on module, unless it is preferred to aggregate all annotations here

I think we would want to have 1 PR (1 commit), instead of having multiple commits of this. Having some large file changes for this is fine with me.

Also, as @ADD-SP mention, we can revert #7518 in this PR.

[lblack00]

Test results yield:
test result: ok. 93 passed; 0 failed; 285 ignored; 0 measured; 0 filtered out; finished in 1.59s

[mox692]

Now the doc test is hitting compile_error! here:

tokio/tokio/src/lib.rs

Lines 463 to 475 in 925c614

	#[cfg(all(
	not(tokio_unstable),
	target_family = "wasm",
	any(
	feature = "fs",
	feature = "io-std",
	feature = "net",
	feature = "process",
	feature = "rt-multi-thread",
	feature = "signal"
	)
	))]
	compile_error!("Only features sync,macros,io-util,rt,time are supported on wasm.");

(it looks like cargo test --lib wouldn't hit this cfg, but cargo test --doc does.)

You could update the cfgs in the ci settings like this:

- cargo test -p tokio --target ${{ matrix.target }} --features full
+ cargo test -p tokio --target ${{ matrix.target }} --features "sync,macros,io-util,rt,time"

[mox692]

Looks good to me.

[ADD-SP]

See #7537 (comment), It might be a cargo issue, we'd better having a minimal reproducible example, otherwise, it is hard for me to say that I know what I am doing.

[ADD-SP]

I made an minimal reproducible example, it seems unrelated to neither Rust version nor wasm. If I understand correctly, since there is a not(my_unstable), the compile_error! should never fire.

@mox692 Do you have any idea? It look like a Cargo issue.

[package]
name = "feature-flag"
version = "0.1.0"
edition = "2024"

[dependencies]

[features]
epoll = []

[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(my_unstable)'] }

// src/lib.rs
#[cfg(all(
    not(my_unstable),
    any(
        feature = "epoll",
    )
))]
compile_error!("blablabla");

# no error
RUSTFLAGS="--cfg my_unstable" cargo +1.88 test --lib --features epoll
RUSTFLAGS="--cfg my_unstable" cargo +1.89 test --lib --features epoll

# compilation error
RUSTFLAGS="--cfg my_unstable" cargo +1.88 test --doc --features epoll
RUSTFLAGS="--cfg my_unstable" cargo +1.89 test --doc --features epoll

[mox692]

Not sure. It looks like cfg isn't passed to cargo properly. It's probably worth filing an issue on cargo side?

[lblack00]

@ADD-SP This does not trigger compile_fail! on minimal example:

# no error on --doc
RUSTFLAGS="--cfg my_unstable" RUSTDOCFLAGS="--cfg my_unstable" cargo +1.88 test --doc --features epoll
RUSTFLAGS="--cfg my_unstable" RUSTDOCFLAGS="--cfg my_unstable" cargo +1.89 test --doc --features epoll

# no error on --lib
RUSTFLAGS="--cfg my_unstable" cargo +1.88 test --lib --features epoll
RUSTFLAGS="--cfg my_unstable" cargo +1.89 test --lib --features epoll

If we run cargo +1.88 test --doc --features epoll with only RUSTFLAGS or RUSTDOCFLAGS, then compile_fail! is triggered:

RUSTDOCFLAGS="--cfg my_unstable" cargo +1.88 test --doc --features epoll

   Compiling foo v0.1.0 (/.../foo)
error: blablabla
 --> src/lib.rs:8:1
  |
8 | compile_error!("blablabla");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `foo` (lib) due to 1 previous error

RUSTFLAGS="--cfg my_unstable" cargo +1.88 test --doc --features epoll

    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.19s
   Doc-tests foo
error: blablabla
 --> src/lib.rs:8:1
  |
8 | compile_error!("blablabla");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error

error: doctest failed, to rerun pass `--doc`

I believe this boils down to how running cargo test --doc compiles a crate using rustc and rustdoc, where RUSTFLAGS are passed to rustc and RUSTDOCFLAGS are passed to rustdoc. Even if there are no doctests, running the minimal example without RUSTDOCFLAGS will fail as rustdoc compiles in a separate context than rustc and --cfg=my_stable isn't passed to rustdoc.

[ADD-SP]

I think there are several tests don't need to be ignore-wasm, we could enable it.

By the way, and not a blocker, I think its ok to remove the async fn main in the rendered docs.

/// # /*
/// #[tokio::main]
/// # */
/// # #[tokio::main(flavor = "current_thread")]
/// async fn main() {
///     let mut none = stream::empty::<i32>();
///
///     assert_eq!(None, none.next().await);
/// }
/// 

So we can do this, and it looks less confusing while reading the tokio source.

/// # #[tokio::main(flavor = "current_thread")]
/// async fn main() {
/// let mut none = stream::empty::<i32>();
///
/// assert_eq!(None, none.next().await);
/// # }
/// 

[ADD-SP]

Could we enable this test?

[lblack00]

I initially couldn't get this test to be enabled until I lowered the memory allocated in the test from 64KiB to 16KiB, specifically for the threads runner.

I tried using futures::executor::block_on and adjusting the max memory limit of the test in RUSTFLAGS but neither seemed to work. Neither did simply adjusting the flavor to current_thread.

Not sure what the deeper problem is there. Except maybe it's just due to the single-threaded execution?

[lblack00]

I removed async fn main from rendered docs except for two instances that I thought came down to either sacrificing some syntactic confusion or readability for docs. Let me know if these aren't appropriate.

tokio/tokio-stream/src/stream_ext.rs

Lines 515 to 518 in 58f199e

	/// # /*
	/// #[tokio::main]
	/// # */
	/// # #[tokio::main(flavor = "current_thread")]

tokio/tokio-util/src/io/sync_bridge.rs

Lines 107 to 110 in 58f199e

	/// # /*
	/// #[tokio::main]
	/// # */
	/// # #[tokio::main(flavor = "current_thread")]

[ADD-SP]

I think there are still some doc tests should not be disabled on wasm, this is still not a exhausted list, you might find more by scanning this PR.

I use this screenshot to illustrate my concerns.

I rendered the docs of tokio::task using this PR. Using too many exclamation marks in docs can make it a less enjoyable read for downstream.

[lblack00]

There's 108 tests remaining that still have ignore-wasm annotations, which are primarily due to features unavailable on WASM targets. Such as: fs, net, rt-multi-threaded, etc...

Although, a common exception to this are these tests, for example, with blocking mechanisms (marked by *):

* tokio/src/runtime/builder.rs - runtime::builder::UnhandledPanic::Ignore (line 154)
tokio/src/runtime/task/error.rs - runtime::task::error::JoinError::is_panic (line 48)
tokio/src/runtime/task/join.rs - runtime::task::join::JoinHandle (line 108)
* tokio/src/sync/broadcast.rs - sync::broadcast::Receiver<T>::blocking_recv (line 1524)
* tokio/src/sync/mpsc/unbounded.rs - sync::mpsc::unbounded::UnboundedReceiver<T>::blocking_recv (line 299)
* tokio/src/sync/oneshot.rs - sync::oneshot::Receiver<T>::blocking_recv (line 1191)
* tokio/src/sync/rwlock.rs - sync::rwlock::RwLock<T>::blocking_read (line 491)
* tokio/src/sync/rwlock.rs - sync::rwlock::RwLock<T>::blocking_write (line 833)
* tokio/src/task/join_set.rs - task::join_set::JoinSet<T>::spawn_blocking (line 211)
tokio/src/task/mod.rs - task (line 93)

[ADD-SP]

Thanks for you patient! I think we have enabled most of tests, the remaining part is a bit tricky.

[ADD-SP]

Overall look good to me.

[ADD-SP]

Thank you very much!