Repository navigation
fix: resolve Rust super:: and self:: calls through the written path - #1110
Conversation
|
Warning Review limit reached
Next review available in: 1 minute You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughRust prefixed calls now resolve against declared inline-module scopes before fallback probes. Implementation blocks no longer add false module nesting. Regression tests cover ChangesRust module-qualified call resolution
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant CallProcessor
participant CallResolver
participant ModuleScopes
participant ResolutionCache
CallProcessor->>CallResolver: pass declared inline-module names
CallResolver->>ModuleScopes: inspect enclosing inline modules
ModuleScopes-->>CallResolver: return valid module scopes
CallResolver->>ResolutionCache: cache resolved or known-unresolved result
Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Greptile SummaryThe Rust resolver now uses the set of declared inline modules to distinguish module scopes from implementation scopes. This keeps Confidence Score: 5/5No blocking failure remains. No accepted blocking findings remain after confirming the resolver excludes primitive implementation scopes and retains declared inline-module scopes.
What T-Rex did
Reviews (2): Last reviewed commit: "fix: decide Rust inline-mod scopes by in..." | Re-trigger Greptile |
|
Confirmed and fixed in 880ea5d — thanks, this was a real defect and the reproduction was exactly right. I reproduced it before changing anything. The root cause is that my discriminator was an absence test. Probing the registry directly showed why it cannot work: Both are The fix replaces it with a positive membership test against Regression test added to |
|
|
@coderabbitai full review @greptile-apps review All review threads on this PR have been answered inline: findings implemented, or explicitly rebutted with the reasoning. Please re-assess against the current head and confirm whether this is ready to merge. |
Rate Limit Exceeded
|
|
@coderabbitai full review |
|



Closes #1093.
Root cause, confirmed by reproduction
The issue's corpus reproduces exactly:
_try_resolve_via_importsanswerssuper::helper()with the caller's OWNhelper, never honouring the prefix, and it runs before_try_resolve_rust_module_qualified— so_resolve_rust_prefixed_path, which knows how to climb, is never reached.Changes
1. The prefixed-path probe gets first refusal. A call whose first segment is
crate::/self::/super::says outright which module holds the item, so it must not reach probes that answer by name. Undecided still falls through to every existing fallback, so nothing else changes.2. The enclosing-scope bail now distinguishes an impl block from an inline mod.
_resolve_rust_prefixed_pathdeclined any caller nested below the file module because the two are "indistinguishable in qn space". They are distinguishable via the type registry: new_rust_enclosing_mod_scopesfilters out scopes registered asClass/Interface/Enum/Type/Union(newRS_TYPE_SCOPE_LABELS). An impl block adds no module level, so a method'ssuper::counts from the file module's parent exactly as a free function's does.Change 1 alone fixes the free-function case; the issue's headline repro is inside an
impl, which needs change 2 as well.This does not encroach on #1086. A genuine inline
modchain still triggers the bail and keeps today's behaviour. Only impl targets are filtered out.Tests
codebase_rag/tests/test_rust_super_self_prefix_calls.py:super::from inside animplself::helper()— the adjacent case the issue flags, pinned so the outer same-named item cannot winsuper::with no local shadow, which used to drop rather than bind wronglyuse super::item;, out of scope here, pinned so the reordering does not disturb itTwo fail without the fix; all five pass with it.
Regression coverage
Full unit suite: 6502 passed, 79 skipped, no failures.
ruffandtyclean.Summary by CodeRabbit
Bug Fixes
crate::,self::, andsuper::.super::behavior from implementation blocks and free functions.use super::...imports and calls without local name shadowing.Tests