[kixelated]

Problem

rust2-ts still refused part of std's guard API after #384: Debug and Display of every guard (Ref, RefMut, MutexGuard, the RwLock guards, mapped or not), MutexGuard::map and filter_map with the MappedMutexGuard they make, and the unstable Ref::try_map and RefMut::try_map.

Approach

• Printing: a guard writes what it lends by that value's own Debug or Display, as std's impls do, through rt.fmt* with the caller's options. A field of a tuple element (value[0].value) is now pure in fmt.rs, so Debug of a tuple holding a guard needs no statements. Result::unwrap of a try_map hits that case.
• Mutex maps: MappedMutexGuard is Std::MutexGuard, so its deref, drop, and type lower as a MutexGuard's do. A map makes an rt.MutexMap, a Mapped of where its part is that forwards locked to the guard it took over. mutexUnlock stays one property write with no instanceof. RefMap and MutexMap share the Mapped base for reading and writing through a place.
• try_map: reuses guard_map. Ok holds a guard of the part, at its place where an exclusive guard needs one. Err gives the guard back beside the error, as the tuple [guard, error].
• Tests: three lang-fixture differential cases against native wasm32: borrows::tries, locks::mutex_mapped, and locks::printed. They cover writes through mapped guards, parts JS copies and parts it doesn't, whole writes, an error that drops, release when the last guard drops, and {:?}, {:#?}, and padded Display. Mutex lock state is checked through try_lock, since locking twice aborts on wasm32 (quest ts-abort-differential).

Impact

• Translated output: rt.MutexMap, rt.mutexMap, rt.mutexFilterMap, rt.refTryMap, and rt.refMutTryMap are new runtime exports. No config or CLI change. Nothing breaks, so no MIGRATE.md entry.
• Consumer: the m3 goal of translating all of std. No translated moq code calls these today: moq-ffi maps only tokio's guards, and moq-ffi is not translated.

Alternatives

• Make rt.Mutex an rt.RefCell so RefMap covers both. I rejected this because the two fail differently on conflict (a mutex's relock message, a cell's borrow counts), and every Mutex would then pay for borrow counting.
• Look up the underlying mutex with instanceof on unlock, as refCellOf does for cells. I rejected this to keep the unlock of a plain MutexGuard a single write.

Follow-ups

• None found within scope.

Review

mechanical fix by codex / Codex: Merged base, preserving both guard and capacity test cases in three conflicts; regenerated harness snapshot. Passed in ts/ with pinned nightly: UPDATE_EXPECT=1 cargo test --locked -p rust2-ts --test fixtures lang -- --exact; cargo test --locked -p lang-fixture; cargo test --locked -p rust2-ts --bin rust2-ts --test runtime; cargo clippy --locked -p rust2-ts --all-targets -- -D warnings; cargo fmt --all --check; tsc -p runtime. All 365 language snapshots match generated output. (head 11870f9)

• Reviewer: Codex, gpt-6.1-sol, medium effort, via quest review --base origin/main.
• Head reviewed: 9a10b59, round 2, with no findings.
• Round 1, medium, ts/fixtures/lang/src/borrows.rs:572: a cell's shared guard was still alive when its exclusive guard was borrowed, so the printing branch of borrows::tries always panicked. Fixed: the two guards now print in separate statements.

🤖 Generated with Claude Code

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 130ede85-2ad6-4a34-8604-4ffff6b5ce55

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[kixelated]

On wasm32, locking a Mutex again while it is held is a panic, not an abort. sys/sync/mutex/no_threads.rs uses assert_eq!(self.locked.replace(true), false, "cannot recursively acquire mutex"), and rt.mutexLock already panics with that exact message, which locks::relock compares today. So locks::mutex_mapped can test re-locking while a MappedMutexGuard holds the mutex directly, without going through try_lock. RwLock is the one that aborts, and #393 makes the differential compare those aborts.

(written by Claude Opus 5.5)

[moq-bot]

quest land removed this pull request from the queue: Conflicts with the base: ts/fixtures/lang/caller.ts, ts/fixtures/lang/expected/harness.ts, ts/fixtures/lang/src/harness.rs
.