moreal · Jul 20, 2026 · Jul 20, 2026 · Jul 20, 2026 · Jul 20, 2026 · Jul 22, 2026
diff --git a/.agents/skills/apple-container/SKILL.md b/.agents/skills/apple-container/SKILL.md
@@ -0,0 +1,63 @@
+---
+name: apple-container
+description: Run RustPython tests in Apple's `container` CLI Linux environment. Use when user asks to run or compare Linux test results on macOS.
+allowed-tools: Bash(container:*) Bash(cargo:*) Read Grep Glob
+---
+
+# Run Tests in Linux Container (Apple `container` CLI)
+
+Run RustPython tests inside a Linux container using Apple's `container` CLI.
+NEVER use Docker, Podman, or any other container runtime. Only use the `container` command.
+
+## Arguments
+
+- Test command to run (examples: `test_io`, `test_codecs -v`, `test_io -v -m "test_errors"`)
+
+## Prerequisites
+
+- The `container` CLI is installed via `brew install container`.
+- The dev image `rustpython-dev` is already built.
+
+## Workflow
+
+1. Check whether the test container is already running:
+
+   ```shell
+   container list 2>/dev/null | grep rustpython-test
+   ```
+
+2. Start the container if it is not running:
+
+   ```shell
+   container run -d --name rustpython-test -m 8G -c 4 \
+       --mount type=bind,source="$(pwd)",target=/workspace \
+       -w /workspace rustpython-dev sleep infinity
+   ```
+
+3. Run the requested test command inside the container:
+
+   ```shell
+   container exec rustpython-test cargo run --release -- -m test <test-args>
+   ```
+
+4. Report results:
+
+- Show pass/fail summary and expected failures / unexpected successes.
+- Highlight new failures compared to macOS results, if available.
+- Do not stop or remove the container after testing.
+
+## Notes
+
+- The workspace is bind-mounted, so local code changes are immediately available in the container.
+- Use `container exec rustpython-test sh -c "..."` for any command inside the container.
+- Rebuild after code changes with:
+
+  ```shell
+  container exec rustpython-test sh -c "cargo build --release"
+  ```
+
+- Stop the container when explicitly requested:
+
+  ```shell
+  container rm -f rustpython-test
+  ```
diff --git a/.agents/skills/investigate-test-failure/SKILL.md b/.agents/skills/investigate-test-failure/SKILL.md
@@ -0,0 +1,53 @@
+---
+name: investigate-test-failure
+description: Investigate a failing RustPython test, compare with CPython behavior, and decide whether to implement a fix or prepare incompatibility issue details.
+allowed-tools: Bash(python3:*) Bash(cargo run:*) Bash(gh issue create:*) Read Grep Glob Bash(git add:*) Bash(git commit:*) Bash(cargo fmt:*) Bash(git diff:*) Task
+---
+
+# Investigate Test Failure
+
+Investigate why a specific test is failing and determine whether it can be fixed now or should be reported as an incompatibility issue.
+
+## Arguments
+
+- Failed test identifier (example: `test_inspect.TestGetSourceBase.test_getsource_reload`)
+
+## Workflow
+
+1. Analyze the failure cause:
+
+- Read the test code.
+- Analyze failure message and traceback.
+- Check related RustPython implementation code.
+
+2. Verify behavior in CPython:
+
+- Run the test with `python3 -m unittest`.
+- Document expected behavior/output.
+
+3. Determine fix feasibility:
+
+- Simple fix (import issues, small logic bugs): implement fix, run formatting and checks, review changes, and commit.
+- Complex fix (major missing feature): gather issue information and report to user.
+
+Pre-commit review process:
+
+- Run `git diff` to review local changes.
+- Use a focused subagent review to compare implementation against CPython behavior and check for missed edge cases.
+- Commit only after review passes.
+
+4. For complex issues, collect issue information using `.github/ISSUE_TEMPLATE/report-incompatibility.md`:
+
+- Feature: missing or broken Python feature.
+- Minimal reproduction code.
+- CPython behavior (`python3`).
+- RustPython behavior (`cargo run`).
+- Python documentation reference link.
+
+Report the collected information to the user. Create an issue only when explicitly requested.
+
+Example issue command:
+
+```shell
+gh issue create --template report-incompatibility.md --title "..." --body "..."
+```
diff --git a/.agents/skills/rustpython-capi-expansion/SKILL.md b/.agents/skills/rustpython-capi-expansion/SKILL.md
@@ -0,0 +1,60 @@
+---
+name: rustpython-capi-expansion
+description: Implement missing RustPython C-API functions in crates/capi using the pyo3-ffi header split mapping (`pyo3-ffi/src/*.rs`, mirroring CPython C API headers). Use this whenever the user asks to add or port C-API functions (for example from setobject.h, dictobject.h, unicodeobject.h) or add capi tests.
+---
+
+# RustPython C-API Expansion
+
+Use this workflow for adding missing C-API functions to RustPython.
+
+## Source of truth for target files
+
+- Use this mapping source: `pyo3-ffi/src/*.rs`, which mirrors the CPython header split used by the C API.
+- Map requested header APIs to `crates/capi/src/<header_basename>.rs` using that split. Examples:
+  - `setobject.h` -> `crates/capi/src/setobject.rs`
+  - `dictobject.h` -> `crates/capi/src/dictobject.rs`
+  - `unicodeobject.h` -> `crates/capi/src/unicodeobject.rs`
+- Do not invent alternate target modules when the header split implies a direct target.
+- If the target file is not present yet, create it and wire it in `crates/capi/src/lib.rs`.
+
+## Implementation workflow
+
+1. Identify requested missing APIs from the user request and their originating C API header.
+2. Open nearby capi modules in `crates/capi/src/` and follow existing style and patterns.
+3. Implement only the requested functions in the mapped target file.
+4. Keep behavior aligned with CPython C-API contracts.
+5. Prefer using existing `rustpython-vm` functionality as much as possible instead of re-implementing behavior in capi.
+6. If a needed `rustpython-vm` helper exists but is private, make it public with a minimal, focused visibility change.
+7. Prefer direct contract assumptions over defensive null checks unless required by the established local style.
+8. Add basic tests only; do not overfit with very specific edge-case clutter.
+9. In tests, use `pyo3` only as a safe wrapper over the API. Avoid raw pointer-heavy direct FFI-style tests.
+10. Run tests from `crates/capi`.
+
+## Testing rules
+
+- Run test commands with working directory set to `crates/capi`.
+- Prefer targeted tests first (module/function filter), then broader capi tests if needed.
+- Keep test names concise (no required `test_` prefix).
+
+## Style rules
+
+- Follow existing RustPython capi coding style in neighboring files.
+- Reuse `rustpython-vm` methods and types first; avoid duplicating VM logic in capi wrappers.
+- When exposing previously private VM helpers, keep the API surface minimal and avoid unrelated refactors.
+- Only expose and implement ABI-stable C-API surface needed for `abi3` / `abi3t`.
+- Add comments only when they explain non-obvious behavior.
+- Keep edits minimal and focused on requested API expansion.
+
+## Completion checklist
+
+- [ ] All requested functions implemented in mapped target file.
+- [ ] New module exported in `crates/capi/src/lib.rs` when applicable.
+- [ ] Basic safe-wrapper `pyo3` tests added/updated.
+- [ ] Tests executed from `crates/capi` and passing for changed area.
+- [ ] Final response includes changed file paths and test command summary.
+
+## Example prompts this skill should handle
+
+- "Implement these missing functions from `dictobject.h`."
+- "Add `setobject.h` C-API functions in RustPython and include basic tests."
+- "Port the listed `unicodeobject.h` APIs in capi, follow existing style, and run tests from `crates/capi`."
diff --git a/.agents/skills/upgrade-pylib-next/SKILL.md b/.agents/skills/upgrade-pylib-next/SKILL.md
@@ -0,0 +1,34 @@
+---
+name: upgrade-pylib-next
+description: Pick the next CPython stdlib module ready for upgrade based on update_lib todo output and skip modules with open upgrade PRs.
+allowed-tools: Skill(upgrade-pylib) Bash(gh pr list:*) Bash(cargo run:*)
+---
+
+# Upgrade Next Python Library
+
+Find the next Python library module ready for upgrade and then run the `upgrade-pylib` workflow for it.
+
+## Workflow
+
+1. Get current TODO status:
+
+```shell
+cargo run --release -- scripts/update_lib todo 2>/dev/null
+```
+
+2. Get open upgrade PRs:
+
+```shell
+gh pr list --search "Update in:title" --json number,title --template '{{range .}}#{{.number}} {{.title}}{{"\\n"}}{{end}}'
+```
+
+3. From TODO output, select modules in this priority order:
+
+- `[ ] [no deps]`
+- `[ ] [0/n]` where dependencies are all upgraded (for example `[0/3]`, `[0/5]`)
+
+4. Skip modules that already have an open upgrade PR.
+
+5. Run upgrade for selected module using the `upgrade-pylib` workflow.
+
+If no modules match, report that eligible modules are blocked by dependencies.
diff --git a/.agents/skills/upgrade-pylib/SKILL.md b/.agents/skills/upgrade-pylib/SKILL.md
@@ -0,0 +1,102 @@
+---
+name: upgrade-pylib
+description: Upgrade a Python standard library module from CPython into RustPython using scripts/update_lib and then triage and mark remaining failures.
+allowed-tools: Bash(git add:*) Bash(git commit:*) Bash(git diff:*) Bash(cargo run:*) Bash(python3 scripts/update_lib quick:*) Bash(python3 scripts/update_lib auto-mark:*)
+---
+
+# Upgrade Python Library from CPython
+
+Upgrade a Python standard library module from CPython to RustPython.
+
+## Arguments
+
+- Library name or path (examples: `inspect`, `asyncio`, `json`, `cpython/Lib/inspect.py`, `cpython/Lib/json/`)
+
+## Important: Report Tool Issues First
+
+If `scripts/update_lib` shows a bug, missing automation, or unexpected behavior, stop the upgrade and report the tooling issue first, including:
+
+1. What you were trying to do:
+
+- Library name.
+- Full command used.
+
+2. What went wrong or what is missing.
+3. Expected vs actual behavior.
+
+## Workflow
+
+1. Run quick upgrade with update_lib:
+
+- `python3 scripts/update_lib quick <module>`
+- or `python3 scripts/update_lib quick cpython/Lib/<module>.py`
+- or `python3 scripts/update_lib quick cpython/Lib/<module>/`
+
+This step copies library files, patches tests while preserving markers where possible, runs tests, auto-marks new failures, removes stale `@unittest.expectedFailure`, and creates a commit.
+
+If warnings like `WARNING: TestCFoo does not exist in remote file` appear, class structure changed and some markers must be restored manually.
+
+2. Review diff and restore RustPython-specific changes:
+
+- Run `git diff Lib/test/test_<module>`.
+- Restore only changes with explicit `RUSTPYTHON` comments.
+- Do not restore unrelated upstream CPython changes.
+
+3. Investigate failing dependent tests:
+
+- Get dependencies:
+
+  ```shell
+  cargo run --release -- scripts/update_lib deps <module>
+  ```
+
+- Find direct dependent test modules from the `- [ ] <module>:` line.
+- Run dependent tests and collect failures:
+
+  ```shell
+  cargo run --release -- -m test <test_modules...> 2>&1 | grep -E "^(FAIL|ERROR):"
+  ```
+
+- For each failing test identifier, investigate with the `investigate-test-failure` workflow.
+
+4. Mark remaining failures with auto-mark:
+
+- `python3 scripts/update_lib auto-mark Lib/test/test_<module>.py --mark-failure`
+- or `python3 scripts/update_lib auto-mark Lib/test/test_<module>/ --mark-failure`
+
+Note: `--mark-failure` marks all current failures including regressions; review carefully.
+
+5. Handle panics manually:
+
+- For tests that panic/crash/hang, use `@unittest.skip("TODO: RUSTPYTHON; ...")` rather than expectedFailure.
+
+6. Handle class-specific failures:
+
+- If only one subclass fails (for example `TestCFoo` but not `TestPyFoo`), move marker to the failing subclass override.
+
+7. Commit test-fix markers as a separate commit:
+
+```shell
+git add -u && git commit -m "Mark failing tests"
+```
+
+## Example usage
+
+```text
+upgrade-pylib inspect
+upgrade-pylib json
+upgrade-pylib asyncio
+upgrade-pylib cpython/Lib/inspect.py
+upgrade-pylib cpython/Lib/json/
+```
+
+## Notes
+
+- The `cpython/` directory should contain the CPython source used for sync.
+- `scripts/update_lib` modes:
+  - `quick`: patch + auto-mark
+  - `migrate`: patch only
+  - `auto-mark`: mark failures only
+  - `copy-lib`: copy library files only
+- Patching transfers `@unittest.expectedFailure` and `@unittest.skip` with `TODO: RUSTPYTHON` markers where possible.
+- The tool does not preserve every RustPython-specific change; always review and restore explicit RUSTPYTHON-marked logic.
diff --git a/.cargo/config.toml b/.cargo/config.toml
@@ -6,3 +6,16 @@ rustflags = "-C link-args=-Wl,--stack,8000000"
 
 [target.wasm32-unknown-unknown]
 rustflags = ["--cfg=getrandom_backend=\"wasm_js\""]
+
+# Enforce a 1 MB stack limit for WASI targets.
+# (Runaway heap growth is fixed by the smaller DataStack chunk
+# and the size‑optimized wasm‑release profile.)
+[target.wasm32-wasip1]
+rustflags = [
+    "-C", "link-arg=-zstack-size=1048576",
+]
+
+[target.wasm32-wasip2]
+rustflags = [
+    "-C", "link-arg=-zstack-size=1048576",
+]
diff --git a/.claude/commands/investigate-test-failure.md b/.claude/commands/investigate-test-failure.md