[kixelated]

Problem

#144 saw the recursion_depth_exceeding_limit future-compat lint fire during just ffi moq, on Send checks in moq-net, moq-tokio, and the stand-in moq_ffi. A later nightly turns it into a hard error.

Findings

Reproduced at the old pin (c764ace): it fired in moq-net (ietf/publisher/tracks.rs async block), moq-tokio (client.rs spawning isolate(time::run(driver)).instrument(..)), and in rust2-ffi's own Send query on moq_mux::import::Container while analyzing the stand-in.

At the pin #196 moved to (30f25c0), a clean just ffi moq emits no instance. The deepest check per crate, found by lowering each crate's recursion_limit (default 128) until the lint fires:

Crate	Deepest check	Depth
moq-tokio	tokio::spawn(isolate(time::run(driver)).instrument(..)): Send	127
moq-net	ietf/publisher/tracks.rs async block: MaybeBoxedExt	105-112
glue (moq)	rt::Object::<track::Subscriber>::borrow: Subscriber: Sync	99-108
rust2-ffi's query in the stand-in	moq_mux::import::Container: Send	97-112
moq-mux		65-96

The glue is not deeper than moq's own code: its deepest check is moq-net's type nesting (Subscriber > track::Cursor > group::Consumer > resume::Recover > ...), plus about one level. Nothing here to fix in rust2-ffi.

moq-tokio's own driver spawn sits one level under the limit: a small addition to moq's driver future brings the lint back. That is moq's code; see Follow-ups.

Approach

Deny the lint on the export's build in just ffi moq, which compiles moq's crates and the glue. Verified: with moq's crates at recursion_limit = 120, the recipe fails with error: overflow evaluating ... Send in moq-tokio; at the default it passes.

Impact

• Public API: none.

Alternatives

• Deny it on the analysis run too, to cover rust2-ffi's own Send query. Dropped: RUSTFLAGS there invalidates the check cache just ffi census shares, rebuilding it right after in nightly CI. The glue's rt::Object bounds repeat the same Send/Sync checks on every exported object, so the export build covers them.
• Raise recursion_limit: not needed, nothing exceeds it.

Follow-ups

• moq-tokio's driver spawn is at depth 127 of 128. Boxing the driver future as dyn Future + Send before isolate/instrument would cut the chain. A moq-side change, not filed: decide whether to record it in moq's tree now or let this deny flag it at the next pin bump.

Checks

• just ffi moq at 30f25c0: ok, no lint. At c764ace: lint reproduced.
• just check, just test: ok.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

[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-29T07:41:51.285578Z	2701e91	New commits
🔒 Security Review	✅ Completed 2026-10-29T07:42:10.469122Z	2701e91	New commits

ℹ️ 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: 4f2212f

No actionable bugs found. Denying this specific lint on the generated export's build is a focused guard, without raising recursion limits or changing generated ABI behavior. The export uses local path dependencies, and Nightly's existing just ffi moq step reaches this build. Keeping the analysis/census invocation unchanged avoids broadening the compiler-flag change beyond the intended gate.

Verification: static inspection of the diff, export recipe, generated dependency setup, pinned nightly, and CI invocation. No export build, reduced-recursion-limit reproduction, tests, or compiler-depth measurements run; the PR's reported results were not independently reproduced.

(Written by review (OpenAI))