Repository navigation
quest(m3): delete Vec::drain from std's MIR - #636
Conversation
Quest-Claim: 5e16ea94798f193b
…it to the maintainer Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
std's Drain needs std structs and writing std functions translated from MIR, which the translator refuses, and pointer arithmetic into arrays of objects, which the epic's 2026-11-01 decision refuses. Even for elements JS copies it ran 3 to 12x slower than the port, which follows std line for line and is tested against native on every `just ci`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kixelated
changed the title
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 37 minutes. View limit details
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. |
kixelated
left a comment
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit 291ea6f against base fd62edf.
No actionable findings. The two-file change removes the Vec::drain MIR quest and its Required-list entry together, without changing runtime ports or tests. Retaining the existing port is consistent with the epic's documented restriction on arithmetic into arrays of object-valued elements. The separate BinaryHeap quest remains listed for its own PR.
Verification limits: GitHub-only static review of the deletion and surrounding epic. I did not run quest validation or reproduce the deleted spike, benchmark measurements, or native differential tests; the reported performance and passing validation remain author-provided evidence. This is a COMMENT, not an approval.
(Written by review (OpenAI))
Summary
Deletes Vec::drain from std's MIR and its link in the ts-unsafe epic. The runtime's port (
rs.vecDrain,rs.byteVecDrain) stays.Why
A spike (branch
spike/vec-drain-mir, now deleted) translatedalloc::vec::drainandVec::drainas the crate's own code:std structs and writing std functions. std's
Drainis a std struct taking&mut Vec, withunsafebodies; translating it from MIR needs std structs and writing std functions (&mut,unsafe) lowered from MIR, which the translator refuses.Elements JS keeps as objects are refused.
as_ptr().add(start),offset_from, andslice::from_raw_partsover such elements need pointer arithmetic into an array of objects, which the epic's 2026-11-01 decision refuses. moq's oneVec::drain(priority.rs:216) is aVec<Waker>.Even for
u8/u32elements it is 3 to 12x slower. CPU time (process.cpuUsage) perslices::drainscall in Node 24, 1024-byte input draining 254 elements of each vector, a range over two interleaved runs on a loaded host:last,countcountAbout 40% of the time is in
Proxyreads and most of the rest in the room'sMap:set_len(start)moves the range and tail into theVec's room, std's code reads them back through aProxyview, andptr::copymoves the tail back one element at a time.The port follows std line for line, and
slices::drainstests it against native (items, drops, panics, forgotten drains) on everyjust ci.The draft's correction that moq's
client.rs:821drain is aVecDeque, not aVec, lived only in the deleted quest; nothing else in the tree cites that line, so it goes with it.Decisions
rs.AtIndex, which would reopen the 2026-11-01 decision).Impact
None: quest files only. No public API or wire change.
Validation
quest check --fix: 50 documents ok.just check: passed (lint, quest).Models
Size: M
Implementer: Claude Code, claude-opus-5-5, high effort
Review
Skipped: a quest-only deletion needs no review round.
(Written by Claude Opus 5.5 with high effort)
🤖 Generated with Claude Code