bugfix(defs): Name macro-call modules by macro name and offset, not raw call text.

[eytan-starkware]

Summary

Anonymous modules generated by item-level inline macro calls are now named after the invoked macro and disambiguated by the call-site byte offset in the file (e.g., make_pair_75) instead of using the full raw syntax text of the call as the module name.

---

Type of change

Please check one:

• Bug fix (fixes incorrect behavior)
• New feature
• Performance improvement
• Documentation change with concrete technical impact
• Style, wording, formatting, or typo-only change

---

Why is this change needed?

Previously, the name of the hidden module wrapping items produced by a top-level inline macro call was derived from the entire raw syntax text of the macro invocation, which produced unwieldy and fragile identifiers. When the same macro is invoked multiple times, each call needs a distinct, stable, and human-readable module name so that full paths of generated items (e.g., free functions) are predictable and debuggable.

---

What was the behavior or documentation before?

The anonymous macro-call module was named by calling get_text_without_trivia on the entire syntax node of the macro call, yielding the raw invocation text as the module name.

---

What is the behavior or documentation after?

The module is named <macro_name>_<byte_offset>, where <macro_name> is the final identifier of the macro's path and <byte_offset> is the call's offset within the source file. For example, two calls to make_pair!() at offsets 75 and 90 produce modules named make_pair_75 and make_pair_90, giving generated functions full paths like test::make_pair_75::a and test::make_pair_90::b. For macros invoked via a qualified path (e.g., helpers::make_pair!()), only the final identifier is used.

A new test file (macro_call_test.rs) and accompanying test data (tests/macro_call) are added to verify full paths for: a single macro call, repeated macro calls producing distinct modules, and a macro invoked via a qualified path.

---

Related issue or discussion (if any)

---

Additional context

The offset-based disambiguation ensures that two calls to the same macro always produce different module names without requiring any global counter or additional state.

[reviewable-StarkWare]

This change is 

[eytan-starkware]

• bugfix(defs): Name macro-call modules by macro name and offset, not raw call text. #10197 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

PR Summary

Medium Risk
Changing macro-call module naming alters full paths and diagnostic text across the compiler; behavior is intentional but any external reliance on the old raw-text module names would break.

Overview
Item-level inline macro calls no longer use the full raw invocation text as the anonymous module name. ModuleId::MacroCall::name now builds {macro_identifier}!_#{byte_offset} from the macro path’s final identifier and the call’s syntax offset (qualified paths still use only the macro name, e.g. make_impl!_#156).

Semantic tests were added so repeated make_impl!() calls produce distinct module paths in trait-conflict diagnostics, including when the macro is invoked as helpers::make_impl!().

^{Reviewed by Cursor Bugbot for commit 4c314ab. Bugbot is set up for automated code reviews on this repo. Configure here.}

[orizi]

@orizi made 1 comment.
Reviewable status: 0 of 4 files reviewed, 2 unresolved discussions (waiting on eytan-starkware and TomerStarkware).

---

crates/cairo-lang-semantic/src/items/macro_call_test.rs line 23 at r1 (raw file):

/// modules generated by item-level inline macro calls.
fn test_macro_call_item_full_paths(
    inputs: &OrderedHashMap<String, String>,

i think you can use diagnostics to "expose" the actual path we provide.

[eytan-starkware]

@eytan-starkware made 1 comment.
Reviewable status: 0 of 5 files reviewed, 1 unresolved discussion (waiting on orizi and TomerStarkware).

---

crates/cairo-lang-semantic/src/items/macro_call_test.rs line 23 at r1 (raw file):

Previously, orizi wrote…

i think you can use diagnostics to "expose" the actual path we provide.

Done.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9075a01. Configure here.}

[orizi]

@orizi reviewed 5 files and all commit messages, made 1 comment, and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on TomerStarkware).

[orizi]

@orizi reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on TomerStarkware).

[gkaempfer]

Security scan complete — no issues detected.

---

Generated by Claude Code