CodeVetter · Repo Unpack · Contributor handoff
tokio-rs/tokio
Begin with the owning manifest, public exports, implementation, and exact feature-gated test. Preserve scheduler, readiness, cancellation, and persistence contracts when making focused changes. Tests and CI were inspected, not executed, and the investigation is bounded rather than exhaustive. The suggested checks below are for a later authorized implementation session; this read-only investigation did not run repository code or modify files.
- Read workspace patches and owning feature tables first: local dependency substitution and empty default features materially affect which implementations and APIs are built.
- For startup changes, read entry::parse_knobs, Builder::build, threaded construction, and Runtime::block_on together; generated wrappers and runtime context must remain coherent.
- For scheduler changes, preserve dual queue/task-list closure and draining order; use the existing Loom racy_shutdown scenario as a relevant lifecycle regression target.
- For networking changes, preserve WouldBlock readiness clearing, accepted-stream readiness initialization, and from_std nonblocking/runtime requirements; tcp_echo is a focused integration target.
- For filesystem changes, inspect both the blocking fallback and unstable Linux io-uring branch; retain the distinction between File::poll_write acknowledgement, flush, and sync_all.
- In an authorized coding session, start with cargo test -p tokio --features full --test tcp_echo or --test fs_file as appropriate; inspect file cfg guards before selecting flags.
- Tests and CI were inspected, not executed: use the defined nextest/doctest split, trybuild harness, and bounded Loom jobs as verification plans rather than recorded passing results.
- Follow the documented Rust 2021 rustfmt invocation rather than cargo fmt; preserve Rust 1.85 compatibility, public documentation, regression tests, and patch/minor versioning expectations.