-
-
Notifications
You must be signed in to change notification settings - Fork 1
Refactor module name resolution #63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- canonicalise sys.path roots and normalise empty entries to the cwd so path-based lookups are stable - add project-marker heuristics to derive dotted names when sys.modules misses a match and extend coverage to enforce behaviour - prefer sys.modules names over filesystem-shaped fallbacks and let trace filters choose the most specific project root
design-docs/adr/0016-module-name-resolution-via-globals-name.md: design-docs/module-name-resolution-deep-review.md: design-docs/module-name-resolution-globals-implementation-plan.md: Signed-off-by: Tzanko Matev <tsanko@metacraft-labs.com>
|
@codex review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
| } | ||
| Err(_) => None, | ||
| }; | ||
| self.filter.set_module_name_hint(code.id(), globals_name); | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honour module-name-from-globals policy when caching hints
The new module_name_from_globals switch is meant to let users fall back to the filesystem based resolver, but the tracer always captures the frame’s __name__ and stores it as a hint (set_module_name_hint). FilterCoordinator::resolve then passes that hint to TraceFilterEngine unconditionally, so filtering decisions and cached module names still rely on __name__ even when the flag is disabled, and the costly frame capture happens regardless. As a result, --no-module-name-from-globals has no effect beyond skipping the early return in derive_module_name, leaving users without a way to disable the new behaviour. Consider gating both the capture and the hint propagation on the policy flag.
Useful? React with 👍 / 👎.
Coverage SummaryRust (lines)
Python (statements)
Generated automatically via |
This is the last PR involved with module-name resolution. We end-up relying on
__name__to compute the module name.