If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/async-rs/async-std shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 9mo ago
• 19 active contributors
• Distributed ownership (top contributor 41% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 9mo ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live async-rs/async-std repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/async-rs/async-std.

What it runs against: a local clone of async-rs/async-std — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in async-rs/async-std | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 296 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of async-rs/async-std. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/async-rs/async-std.git
#   cd async-std
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of async-rs/async-std and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "async-rs/async-std(\\.git)?\\b" \\
  && ok "origin remote is async-rs/async-std" \\
  || miss "origin remote is not async-rs/async-std (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 296 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~266d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/async-rs/async-std"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

async-std is a deprecated async runtime library that provided a drop-in async replacement for Rust's standard library with APIs for tasks, streams, file I/O, and networking. It was built around Rust's native std::future and async/await syntax with its own lock-free executor and thread pool, but has been officially discontinued in favor of the smol project. Single-crate structure: src/ contains core modules (task, stream, io, sync primitives), examples/ has runnable async patterns, benches/ provides performance tests, and docs/ contains a full mdbook-based tutorial with conceptual guides in docs/src/concepts/ and patterns in docs/src/patterns/.

Rust developers who were building async applications and wanted a stdlib-like API without learning a completely different abstraction layer. Primary audience was library maintainers seeking compatibility with Rust's familiar standard library patterns. Note: This is now a legacy project; new users should use smol instead.

The project reached v1.13.2 and was production-ready, but is now officially deprecated and unmaintained. The README explicitly states 'async-std has been discontinued' and recommends migration to smol. Last activity appears to be maintenance-only; it had comprehensive CI (.github/workflows/ci.yml), good test coverage (benches/ directory with mutex, task, task_local benchmarks), and detailed documentation (docs/book.toml with full async tutorial).

High risk for new projects: This codebase is officially discontinued with no active development or maintenance. Upgrading async-std to newer Rust versions, fixing security issues, or handling breaking changes in dependencies (async-global-executor, async-io, futures-lite) will not happen. Existing projects using it should migrate to smol or tokio rather than relying on this repository.

This project is in maintenance-only mode following its discontinuation announcement. No active feature development or bug fixes are expected. The README redirects users to smol (https://github.com/smol-rs/smol), async-io, futures-lite, futures-concurrency, and async-compat as alternatives.

git clone https://github.com/async-rs/async-std.git
cd async-std
cargo build
cargo test
cargo doc --open

Daily commands:

cargo run --example hello_world
cargo test --lib
cargo bench --bench task

• src/lib.rs: Root module exposing the public API surface (task, io, sync, stream, future modules)
• src/task/mod.rs: Core task spawning and execution including block_on, spawn, and sleep functions
• src/io/mod.rs: Async I/O traits (Read, Write, Seek) and implementations for files, sockets, and buffers
• src/sync/mod.rs: Async synchronization primitives (Mutex, RwLock, Barrier, Semaphore, Channel)
• src/stream/mod.rs: Stream trait definition and adapters for async iteration patterns
• Cargo.toml: Feature flags controlling async-global-executor, async-io, and attribute macro dependencies
• docs/src/SUMMARY.md: mdbook structure defining all tutorial chapters and concept documentation order
• examples/: Runnable examples demonstrating task spawning, networking, file I/O, and concurrent patterns

Adding async primitives: See src/sync/ (mutex.rs, rwlock.rs) for lock implementations. Adding I/O operations: Check src/io/ for Read/Write trait implementations. Adding task utilities: Modify src/task/ (block_on, spawn, sleep). Updating docs: Edit files in docs/src/ (concepts/.md for tutorials, patterns/.md for common patterns). Adding tests: Place in tests/ or use #[cfg(test)] modules within source files.

Deprecation Status: This project is officially deprecated; PRs and issues will likely not be reviewed. Executor Selection: Default feature async-global-executor can be swapped for tokio1, tokio02, or tokio03 via feature flags, but mismatched executor versions can cause runtime panics. WASM Support: Features like gloo-timers indicate WASM compatibility, but std feature disables alloc-only builds. Platform-Specific I/O: async-io behavior differs on Windows vs. Unix (kqueue, epoll) and may not work identically. Attribute Macro Dependency: #[async_std::main] requires the optional attributes feature; without it, use task::block_on directly.

• Work-stealing scheduler — The executor uses a lock-free, work-stealing thread pool to distribute async tasks across cores with low overhead—understanding this is key to tuning async-std performance
• Async trait implementations (AsyncRead/AsyncWrite) — async-std provides async versions of std::io::Read/Write (src/io/mod.rs) that are essential for I/O-bound async code; knowing their signatures and usage patterns is fundamental
• Single-allocation task creation — async-std's task system uses a single heap allocation per spawned task, reducing memory fragmentation and GC pressure compared to competitors
• Stream trait and combinators — The Stream trait (src/stream/mod.rs) is async-std's equivalent to Iterator and provides map, filter, take, etc. adapters; it's crucial for async iteration patterns
• Futures-lite lightweight runtime — async-std uses futures-lite (a minimal runtime) for block_on and executor; understanding this dependency explains why async-std is smaller than tokio
• Task-local storage (async TLS) — async-std provides task::local() for task-local variables (see benches/task_local.rs), which differs from thread-local storage and is essential for async context propagation

• smol-rs/smol — Official recommended replacement providing async runtime, executor, and utilities with a simpler, more maintainable design
• tokio-rs/tokio — Alternative production-grade async runtime with more ecosystem integration and active maintenance
• async-rs/async-io — Low-level async I/O primitives that async-std depends on; also works standalone with other runtimes
• async-rs/async-lock — Async synchronization primitives (Mutex, RwLock) that async-std uses internally via the std feature
• rust-lang/futures-rs — Core futures trait definitions and utilities that async-std builds on top of (futures-core, futures-lite, futures-io)

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive migration guide from async-std to smol in docs/src/

Since the README explicitly states async-std is discontinued in favor of smol, there's no dedicated migration documentation. Creating a structured migration guide would be valuable for existing users and help the transition. This should include API mapping examples, executor differences, and pattern adjustments.

• [ ] Create docs/src/migration/index.md with overview and migration roadmap
• [ ] Create docs/src/migration/executor-differences.md comparing async-std executor with smol's
• [ ] Create docs/src/migration/api-mapping.md with side-by-side examples of common tasks
• [ ] Update docs/src/SUMMARY.md to include new migration section
• [ ] Add migration guide reference to README.md after the deprecation notice

Add security policy and vulnerability disclosure workflow

The repo has docs/src/security/policy.md but there's no GitHub Security Policy file (.github/SECURITY.md) or vulnerability disclosure process documented. This is critical for a deprecated library that users still depend on for understanding how to report potential security issues.

• [ ] Create .github/SECURITY.md with vulnerability reporting instructions
• [ ] Document the process for reporting issues privately via GitHub Security Advisories
• [ ] Include contact information and expected response timeframes
• [ ] Link from README.md security section to .github/SECURITY.md
• [ ] Consider adding a GitHub Security Policy workflow to .github/workflows/

Add integration tests covering Tokio compatibility features and examples

The Cargo.toml shows tokio1, tokio02, and tokio03 feature flags but there's no dedicated test file validating that tokio integration works correctly. Adding tests/tokio_compat.rs would ensure the compatibility layer functions properly for users migrating to smol while still using tokio-dependent libraries.

• [ ] Create tests/tokio_compat.rs with tests for tokio1 feature flag integration
• [ ] Add test cases for basic task spawning with tokio executor configured
• [ ] Add test cases for async I/O operations with tokio's runtime
• [ ] Update .github/workflows/ci.yml to run tokio compatibility tests as separate job
• [ ] Document tested tokio versions in docs/src/overview/stability-guarantees.md

• Port the existing Rust 1.63+ examples to demonstrate with smol instead of async-std (see examples/ directory and docs/src/tutorial/) to help users migrate
• Add comprehensive migration guide in docs/src/ comparing async-std APIs to smol, tokio, and futures-lite equivalents with code examples for common patterns in docs/src/patterns/
• Document the lock-free scheduler implementation details in docs/src/concepts/ (similar to tasks.md and futures.md) to preserve knowledge before archive

The async-std project presents significant security concerns due to its official discontinuation and lack of active maintenance. While the codebase structure appears reasonable, the project will not receive security patches for newly discovered vulnerabilities. Critical risks include: (1) unmaintained status with no future security updates, (2) incomplete dependency version specifications creating transitive vulnerability exposure, (3) truncated Cargo.toml making full dependency assessment impossible, and (4) weak supply chain security practices. Organizations using this library should prioritize migration to actively maintained alternatives like 'smol' or 'tokio'. If continued use is necessary, implement strict dependency pinning, regular audits, and additional runtime security monitoring.

• High · Deprecated and Unmaintained Project — README.md, Cargo.toml package description. The async-std project has been officially discontinued in favor of the 'smol' project. The README explicitly states that the project is no longer actively maintained and users are recommended to migrate to alternatives. This means security vulnerabilities discovered in async-std will not receive timely patches. Fix: Migrate to the 'smol' project or other actively maintained async runtimes like tokio. If continued use is necessary, implement additional security monitoring and vendor dependencies with known good versions.
• Medium · Transitive Dependency Risks - Unspecified Versions — Cargo.toml - [dependencies] section. Several dependencies lack explicit version constraints or use loose version specifications (e.g., 'async-lock = { version = "3.1.0", optional = true }'). Without strict version pinning, transitive dependencies could introduce vulnerabilities. The 'async-global-executor', 'async-io', 'futures-lite', and 'gloo-timers' in default features lack version specifications in the snippet. Fix: Use exact version pinning (=X.Y.Z) or carefully review all transitive dependencies. Maintain a Cargo.lock file in version control. Regularly audit dependencies using 'cargo audit' and tools like 'cargo-deny'.
• Medium · Incomplete Dependency Information in Snippet — Cargo.toml - [dependencies] section (appears truncated). The Cargo.toml dependency section appears truncated ('pin-' is incomplete), making it impossible to fully assess all dependencies for known vulnerabilities. This suggests either the file is malformed or the provided snippet is incomplete. Fix: Provide the complete Cargo.toml file. Run 'cargo audit' to check for known vulnerable dependencies in the full dependency tree.
• Medium · Optional Feature Safety - 'docs' Feature Enables Unstable — Cargo.toml - [features] section, specifically docs = ["attributes", "unstable", "default"]. The 'docs' feature enables both 'attributes' and 'unstable' features, which pull in additional unstable and experimental code. While intended for documentation builds, this could inadvertently expose unstable code if the feature is accidentally enabled in production builds. Fix: Ensure 'docs' feature is never enabled for production builds. Use feature validation in CI/CD. Consider separating documentation-only features from development features.
• Low · No Security Policy Enforcement — .github/workflows/ci.yml (content not fully visible), docs/src/security/policy.md. While a security policy document exists (docs/src/security/policy.md), there is no evidence of automated security scanning, SBOM generation, or supply chain security measures in the CI configuration snippet provided. Fix: Implement automated security scanning in CI/CD (cargo audit, cargo-deny, cargo-supply-chain). Generate and maintain SBOMs. Add SAST tools to the pipeline.
• Low · Dual License Structure — Cargo.toml - license field, LICENSE-APACHE, LICENSE-MIT files. The project uses dual licensing (Apache-2.0 OR MIT). While not a security vulnerability per se, dual licenses can create compliance confusion and potential legal issues in restricted environments. Fix: Ensure license compliance is audited in your environment. Use SPDX identifiers correctly and document which license applies to your use case.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.