[kixelated]

Problem

vec_view decided whether a Vec is bytes from the Vec's type, but Vec::as_slice/as_mut_slice passed it the element type T. With T an ADT, vec_view read T's own first type argument:

• Vec<String> (or any argument-less ADT): rustc ICE on type_at(0). This is what just ts census hit at moq-dev/moq@c764ace in #144.
• Vec<Vec<u8>>, Vec<Wrap<u8>>: silently emitted rt.byteVecSlice(...) over a JS array, a miscompile on any pin.

Reproduced on main with the new fixture cases: the String case panicked, and with it removed tsc rejected byteVecSlice over ByteVec[] and Wrap<u8>[].

Approach

vec_view now takes the element type, which all three callers already have (as_slice's T, Deref's Vec argument, and Index's elem_ty). It drops its "a Vec or its element" guess, so no caller can mix the two up again. The other ty::Adt(_, args) helpers (elements, etc.) are only reached with Vec types and were already correct.

The lang fixture's vecs adds as_slice/as_mut_slice on Vec<u8> (a write through the mutable view), Vec<Vec<u8>>, Vec<Wrap<u8>> (a write through the mutable view), and Vec<String>, checked differentially against native.

Finishes quest/m1/ts-vec-view.md and drops its link from quest/m1/ts-utf8.md.

Impact

• Translator output only: Vec::as_slice/as_mut_slice of a non-byte Vec is now the array itself, and no longer an ICE. No exported Rust API changes, no MIGRATE.md.

Alternatives

• Keep vec_view taking the Vec type and build Vec<T, A> in the as_slice arm. That keeps the ambiguous "either type" fallback, so the same bug stays easy to reintroduce.

Follow-ups

• <[T]>::last_mut is refused (unsupported call to core::slice::<impl [T]>::last_mut). I hit it while writing the fixture and used indexing instead. Candidate for the std-coverage quests.

Checks

• just ts test --test fixtures lang: reproduced the ICE and the miscompile before the fix, passes after.
• just ts census at moq-dev/moq@c764ace (feat(ffi): export moq's owned Path #144's pin): ok. At the current pin: ok.
• just check: ok. just ts test: ok. quest check --base origin/main: ok.
• just test: ok.

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-28T07:18:55.762743Z	17886f8	Draft marked ready
🔒 Security Review	✅ Completed 2026-10-28T07:20:25.407703Z	17886f8	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: 17886f8

No actionable bugs found. The direction is sound: giving vec_view an explicit element-type contract removes the ambiguous ADT unwrapping, and the Deref and range-index callers now supply that same type. This is simpler than reconstructing a Vec type at the slice-method caller. The added fixtures cover byte-vector mutable views, nested vectors, generic wrappers and strings, with matching generated TypeScript.

Verification limits: static review of the diff, relevant lowering/call-site context and fixture output only; I did not run the Rust/TypeScript tests or census.

[kixelated]

Merging 17886f8: Codex reviewed this head (code and security) with no findings, Check passed, and quest check --base origin/main passed on the head. No changes since the review, and nothing left to decide. Follow-up from the body: <[T]>::last_mut is unsupported, to be planned via /quest-plan.

(Written by Claude Opus 5.5)