Skip to content

Fix and guard against cross-module export name collisions - #4

Merged
imattau merged 1 commit into
mainfrom
fix/cross-module-export-collisions
Sep 27, 2026
Merged

imattau merged 1 commit into
mainfrom
fix/cross-module-export-collisions

Conversation

@imattau

@imattau imattau commented Sep 27, 2026

Copy link
Copy Markdown
Owner

Summary

Follow-up to imattau/nscript#3, which fixed the NCC-10/NCC-13 operator_for_tag collision found composing both into examples/service-operator-bot.ns. That fix was ad hoc — nothing checks the whole standard library for this class of bug, only whichever modules one program's own use graph happens to pull in.

  • New regression test: built_in_modules_export_no_ambiguous_names_across_the_standard_library (in nscript-modules) replicates nscript-semantics's E4003 ambiguous-export check over every BUILTINS module at once. It found four more real collisions, none previously exercised by any program combining both sides:
    • ncc08.service / ncc09.service → NCC-08's renamed to handover_service
    • ncc00.status / ncc09.status → NCC-09's renamed to authority_status
    • ncc08.state / ncc10.state → NCC-08's renamed to handover_state (coincidentally same name, unrelated signatures/purposes)
    • concord02.Channel / nip28.Channel → concord02's renamed to ConcordChannel
    • concord02.CommunityError / nip72.CommunityError → concord02's renamed to ConcordCommunityError
  • Each rename picked whichever side had fewer real call sites to update (concord02 had none outside its own module file). Updated every affected .nsm module, the runtime pure-function registry + its unit tests, the example/conformance scripts calling the renamed functions, and spec/nostr.md/NCC-PLAN.md.
  • Documented, not fixed: the other issue building the composite example surfaced — top-level/schedule bodies execute via two independent static passes (literal publishes, then bare operation calls) rather than in source order, so a schedule computing a value and publishing it has to move into a handler instead. Recorded as a follow-up in NCC-PLAN.md; a real fix needs the same sequential, data-flow-aware evaluation a handler body already gets — an evaluator change, out of scope here.

Test plan

  • cargo build --workspace — clean
  • cargo test --workspace — all tests pass (249 + 69 CLI + 14 nscript-modules tests, including the new guard test)
  • cargo fmt --check — clean
  • cargo clippy --workspace --tests -- -D warnings — clean
  • nscript check on every touched .ns/.nsm file

🤖 Generated with Claude Code

https://claude.ai/code/session_01D95PWA2fdNfg7nUvUHBeMi


Generated by Claude Code

Add a standard-library-wide test (built_in_modules_export_no_ambiguous_
names_across_the_standard_library) that replicates nscript-semantics's
E4003 ambiguous-export check over every BUILTINS module at once, rather
than only over one program's own import graph. That check found four
collisions beyond the NCC-10/NCC-13 one already fixed:

- ncc08.service / ncc09.service -> ncc08's renamed to handover_service
- ncc00.status / ncc09.status -> ncc09's renamed to authority_status
- ncc08.state / ncc10.state -> ncc08's renamed to handover_state
- concord02.Channel / nip28.Channel -> concord02's renamed to
  ConcordChannel
- concord02.CommunityError / nip72.CommunityError -> concord02's
  renamed to ConcordCommunityError

Each rename picked whichever side had fewer real call sites; concord02
had none outside its own module file. Updates every affected .nsm
module, the runtime pure-function registry and its tests, the example
and conformance scripts calling the renamed functions by their
qualified name, and spec/nostr.md and NCC-PLAN.md.

Also records, as a documented follow-up rather than attempting an
in-scope fix, the other issue examples/service-operator-bot.ns
surfaced: top-level and schedule bodies execute via two independent
static passes (literal publishes, then bare operation calls) rather
than in source order, so a schedule computing a value and publishing
it needs to move into a handler instead. A real fix needs the same
sequential, data-flow-aware evaluation a handler body already gets,
which is an evaluator change out of scope here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D95PWA2fdNfg7nUvUHBeMi
@imattau
imattau merged commit 5c09df8 into main Sep 27, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants