fix: give an inline mod under a trait or impl body a consistent qn (#1018)

[vitali87]

Closes #1018.

The bug

An inline mod declared inside a trait or impl body (e.g. in a const initializer) produced three qns that disagreed, so graph_audit reported an orphan Module node and dangling DEFINES edges:

• Module node: foo.T.inner (trait) / foo.inner (impl — impl target dropped)
• Function DEFINES parent: foo.inner (class/trait scope dropped)
• Contained functions: foo.T.inner.g / foo.S.inner.g (scope kept)

So foo.T.inner had no outgoing DEFINES (orphan), foo.inner -> ...g dangled, and (Module foo.T) -> ... referenced a trait node as if it were a module.

Fix — make node, containment, and items agree

Three aligned changes so the inline mod, its enclosing-module DEFINES, and its items all key the same way:

1. Module node qn (build_nested_qualified_name_for_class, opt-in include_impl_targets): a mod under impl S now keys foo.S.inner, matching the items inside it (foo.S.inner.g), exactly as a mod under trait T already keyed foo.T.inner. Class/struct qns keep the old default, so the change is scoped to the inline-module caller.
2. Function DEFINES parent (_determine_function_parent): derived from the item’s OWN qn (func_qn.rsplit) instead of a mods-only re-walk that dropped the class scope, so it always matches the item and its Module node.
3. Inline-module DEFINES parent (_process_inline_modules): the nearest enclosing MODULE (via a mods-only walk), not the qn’s rsplit prefix — a mod under a trait/impl has a class node (not a module) as that prefix, which would dangle.

Tests

• test_inline_mod_in_a_trait_body_... and test_inline_mod_in_an_impl_body_... (both new): assert the Module node exists at the expected qn and both DEFINES edges (module -> inline mod, inline mod -> its fn) are present and consistent. The conftest graph-audit (which raised the original violations) now passes for both fixtures.
• Full Rust suites: 177 passed, 2 skipped, no regressions. Lint + type-check clean.

Summary by CodeRabbit

• Bug Fixes

  • Improved Rust code navigation and indexing for inline modules nested within traits, implementations, and associated constants.
  • Preserved accurate qualified names and containment relationships for nested functions and modules.

• Tests

  • Added regression coverage for complex Rust trait, implementation, and nested-module scenarios.

[coderabbitai]

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 62231d9a-457c-4857-beb6-71ec03583bf6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Rust parser resolution now preserves trait and impl scopes for inline modules and nested items. Regression tests verify consistent module qualified names and DEFINES relationships.

Changes

Rust inline module qualified-name consistency

Layer / File(s)	Summary
Qualified-name and containment resolution codebase_rag/parsers/class_ingest/identity.py, codebase_rag/parsers/class_ingest/mixin.py, codebase_rag/parsers/function_ingest.py	Qualified-name construction can include impl targets. Inline module and nested-item containment now uses resolved Rust module paths.
Trait and impl regression coverage codebase_rag/tests/test_rust_crate_path_trait_linking.py	Tests cover inline modules in trait and impl-associated const bodies, nested modules, qualified names, and DEFINES edges.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• vitali87/code-graph-rag#1027: Modifies Rust qualified-name and inline-module containment handling in class_ingest/mixin.py.
• vitali87/code-graph-rag#1068: Modifies Rust nested-definition containment in function_ingest.py.
• vitali87/code-graph-rag#1163: Addresses inline modules in trait and impl scopes with regression tests in the same test file.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes address issue #1018 by aligning module, function, and inline-module qualified names and DEFINES relationships for trait and impl scopes.
Out of Scope Changes check	✅ Passed	The changes remain within issue #1018 and add only the required qualified-name fixes and regression tests.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The description clearly explains the bug, fix, related issue, affected scopes, regression tests, and validation results, but omits the template's checkbox sections.
Title check	✅ Passed	The title clearly and concisely describes the fix for inconsistent qualified names under trait or impl bodies.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/1018-inline-mod-class-scope-qn

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@codebase_rag/parsers/class_ingest/mixin.py`:
- Around line 1751-1756: Update the parent qualified-name construction in the
module-ingestion logic around rs_utils.build_module_path so nested inline
modules retain the enclosing trait or impl scope. Resolve the nearest enclosing
Module using its scoped qualified name rather than joining unscoped module
names, preserving valid DEFINES edges for cases such as foo.T.outer.inner. Add
regression coverage for nested modules inside traits and impls.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 3e4ecd95-4bce-4b9c-8d20-f34e72eb6d75

📥 Commits

Reviewing files that changed from the base of the PR and between 98ee35b and 7600a7e.

📒 Files selected for processing (4)

• codebase_rag/parsers/class_ingest/identity.py
• codebase_rag/parsers/class_ingest/mixin.py
• codebase_rag/parsers/function_ingest.py
• codebase_rag/tests/test_rust_crate_path_trait_linking.py

[greptile-apps]

Greptile Summary

The previously reported P1 nested inline-module containment defect is fixed. The focused Rust regression test passed, and an end-to-end graph update confirmed that foo.T.outer defines foo.T.outer.inner while the former dangling foo.outer source is absent.

Confidence Score: 5/5

No blocking failure remains; the containment relationship is correctly preserved for nested inline modules in trait scope.

There are no accepted P0 or P1 findings. The reported P1 was disproved by the targeted regression and an end-to-end graph update exercising the same nested trait-body module shape.

_{Reviews (2): Last reviewed commit: "fix: point a nested inline mod's DEFINES..." | Re-trigger Greptile}

[vitali87]

@coderabbitai I've pushed a fix for the nested inline-mod parent qn and added a regression test. Please re-review.

[coderabbitai]

@vitali87 I will re-review the updated nested inline-module qualified-name handling and regression test.

⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[vitali87]

@greptileai Fixed the nested inline-module containment (P1) and added a regression test. Please re-review.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud