[kixelated]

Problem

Two UniFFI crates linked into one library could not each export a type with the same name, so media.GroupConsumer(group: GroupConsumer) was impossible: every generator built on ComponentInterface refused it with conflicting types, and Python silently dropped the local type (mozilla/uniffi-rs#3026, unfixed upstream). This finishes the namespaces quest; moq's per-layer crate split (moq-dev/moq#5460) is the consumer.

Approach

• Core (uniffi_bindgen): TypeUniverse, the set of errors, and the recursion graph key named types by crate and name. is_name_used_as_error(name) becomes is_used_as_error(&ty), get_type(name) is local-only, and the recursive type walk resolves an external type in its own crate's interface instead of falling back to a same-named local one (also when the type lives in a submodule).
• Python: cherry-picks mozilla/uniffi-rs#2985 (the sort no longer drops a same-named definition), keys the pipeline's errors and recursion by namespace, and names container helpers for an external type after its namespace.
• Every generator references another crate's type through that crate's module, and names the helpers it generates for containers of an external type after its namespace (SequenceNetTypeFrame next to SequenceTypeFrame):
  • Kotlin: fully qualified packages (no imports that a local type can shadow), carried by a KotlinCi { ci, config } context.
  • Swift: qualifies an external type with its module only when its name is ambiguous, and imports that module. Same-named types need one Swift module per crate; everything else keeps the single-module layout and output. The test harness compiles one module per crate when the bindings import each other.
  • Go: already package-qualified; error checks are type-aware.
  • Dart: imports another crate's library as uniffi_<namespace> (a bare net prefix is hidden by a member named net). The shared runtime now comes from the same crate every run, and the harness drives library mode.
  • C++: global-namespace qualification (::net::Frame), aliased converters, per-crate definition sort and strip_type_prefix.
  • C: supports external types (it refused them before); every C name carries its namespace, and a consumer compiles each crate's C output.
• Fixture uniffi/fixtures/namespaces/{net,media}: both export GroupConsumer, Frame, Priority, and GroupError, each media type holds or wraps its net namesake, and containers hold both. Kotlin, Swift, Python, Go, Dart, C++, and C each compile and run a consumer.

No FFI contract change: metadata, checksums, and scaffolding are untouched, so the contract quest stays as it is.

Proof: moq-ffi bindings are byte-identical

moq-ffi at moq-dev/moq@4a16316 (default features, crates.io uniffi 0.32), generated for Kotlin, Swift, and Python (--no-format), Go, Dart (dart/uniffi.toml, --no-format), and C++ (cpp/moq/uniffi.toml):

Generators	Result
moq's pins (kixelated/uniffi-rs@88d835d, Go v0.10.0-kixelated.1, moq's flake Dart and C++)	baseline
this branch	all 17 files byte-identical

The C backend refuses moq-ffi with both, with the same error (duplicate moq_audio_encoder_finish). Each generator's fork also diffed its own single-crate fixtures before and after: identical. Only crates with external types change.

Checks

• just check and just test pass.
• just uniffi fixtures in nix develop .#uniffi: 355 nextest tests (Kotlin, Swift, Python, Dart fixtures, including the new namespaces consumers), 60 bindgen tests, Go go test, and 33 C++/C ctest cases pass. The new C++ and C consumers are clean under valgrind memcheck (run by hand, since valgrind is not in the dev shell).
• One local caveat: the Kotlin harness also loads the cdylib from target/debug, so a stale dev build of a fixture fails with UnsatisfiedLinkError until rebuilt. CI builds from clean.

Impact

• uniffi_bindgen (breaking, in uniffi/MIGRATE.md): ComponentInterface::is_name_used_as_error is replaced by is_used_as_error(&impl AsType); get_type finds only local types; find_component_interface accepts a module path; VisitMut::visit_error_name takes the defining module path.
• Generated code for crates that use another crate's types: external references are qualified (Kotlin, Swift when ambiguous, Dart, C++), and private container helper names change. Single-crate output is unchanged.
• Generated C: external types are supported; every name carries the namespace prefix (breaking for a crate whose items lacked it; in uniffi/MIGRATE.md).
• New fixtures: uniffi-fixture-namespaces-{net,media} and dart_namespaces (unpublished).

Alternatives

• Qualify only colliding names everywhere: smaller diffs for existing multi-crate users, but every generator would need collision detection; always qualifying is simpler where the language allows it. Swift is the exception, because qualification needs per-crate modules and the documented layout is one module.
• Thread-local context for Kotlin's packages and Swift's modules: smaller diff, but hidden state; both pass context explicitly.
• Wait for upstream: the issue is unfixed on uniffi main.

Follow-ups

• moq: re-run the per-layer crate split decision (rejected in quest(m1): binding namespace spike is a no-go moq-dev/moq#5460) on this fork.
• Generated qualifiers can still be hidden by a generated member with the same name as a package root (for example a Kotlin field named uniffi); Dart avoids it with its uniffi_ prefix, C++ with ::.
• uniffi-bindgen-swift's xcframework path compiles all crates into one module, so same-named types still cannot use it.
• In Go and Dart, the container helpers for an external net::Frame and for a local type named NetFrame share a name. The generated code then fails to compile instead of mixing them up.

(written by Opus 5.5)

🤖 Generated with Claude Code

https://claude.ai/code/session_0115AT2ue6x9cT5e5J9SZtCn

[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-24T17:06:47.395461Z	8670b55	New commits
🔒 Security Review	✅ Completed 2026-10-24T17:08:10.182599Z	8670b55	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.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: da5520b0b9

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Resolve an external enum's shape in its defining interface

When a local flat enum and an external data-carrying enum share a name, a variant containing the external enum is serialized incorrectly. The is_flat_enum helper still calls type_helper.get_enum(name), which looks up the local namesake, while the converter now correctly refers to the external enum. Consequently, allocation and writing reserve and copy only four bytes, discarding the external enum's payload; reading likewise passes only its discriminant to the external converter. Resolve the enum definition through its owning component, or use the converter's normal read/write/allocation methods without this special case.

AGENTS.md reference: AGENTS.md:L15-L15

Useful? React with 👍 / 👎.

[kixelated]

Fixed in 899cc21: is_flat_enum now resolves the enum in the crate that defines it. The fixture gained a data-carrying net::Kind next to a flat media::Kind, both held by media::Track variants; the Dart test failed with a RangeError before the fix and passes after.

(written by Opus 5.5)

[chatgpt-codex-connector]

Import all dependencies when Swift requires separate modules

When a library contains a name collision plus an unambiguous dependency from another crate, this early continue omits an import required by the separate-module layout. For example, if media defines Frame, uses net::Frame, and also uses extra::Other, the generated Swift imports net but neither imports extra nor qualifies Other. The updated Swift test runner splits every crate into its own module as soon as any collision requires an import, so Other and its converters are then out of scope. Determine the module layout across the components and include every external dependency's module when using the split layout, rather than importing only types whose names collide.

Useful? React with 👍 / 👎.

[kixelated]

Fixed in 899cc21: once any crate in the library needs its own Swift module, every crate's bindings import every crate they use, not only the ones they qualify. The layout is decided across components in apply_renames (separate_modules). A unit test with a third crate's unambiguous type fails on the old code and passes now.

(written by Opus 5.5)

[kixelated]

Merging at 8670b55.

• Same-named types across UniFFI crates now work in every generator (Kotlin, Swift, Python, Go, Dart, C++, C), with the namespaces/{net,media} fixture as proof; moq-ffi bindings stay byte-identical.
• Codex's two findings (Dart enum shape lookup, Swift split-layout imports) are fixed in 899cc21 and answered; its re-review of 899cc21 found nothing.
• 8670b55 only merges main (feat(bench): attribute an edit rebuild by unit, critical path, and stage #22, feat(ts): translate iterators through a DONE protocol #23, feat(ts): emit each module in Rust source order #27, fix(ts): type-check values of type ! where a value goes #28; fix(uniffi): write scaffolding atomically so concurrent expansions never include a partial file #25 was already merged in), with no conflicts. just check, just test and just uniffi fixtures pass locally (355 nextest, Go, 33 ctest), CI is green, and quest check --base origin/main passes.

(written by Opus 5.5)