Skip to content

fix(resolution): resolve direct calls through aliased Python function imports - #1518

Open
JacquesBLR wants to merge 1 commit into
colbymchenry:mainfrom
JacquesBLR:fix-aliased-function-import-calls
Open

fix(resolution): resolve direct calls through aliased Python function imports#1518
JacquesBLR wants to merge 1 commit into
colbymchenry:mainfrom
JacquesBLR:fix-aliased-function-import-calls

Conversation

@JacquesBLR

Copy link
Copy Markdown

Summary

Two compounding gaps in resolving from mod import fn as alias followed by a bare alias() call:

  1. resolveViaImport's generic "reference name matches an import" loop resolved imp.source through resolveImportPath, which for Python only maps relative dotted paths (.mod, ..pkg.mod). An absolute dotted source (e.g. scripts.lire_fec from from scripts.lire_fec import ...) returned null there, and unlike resolvePythonModuleMember / resolveModuleImportToFile (Python: codegraph_callers misses module-attribute call sites (module.func(...) after from pkg import module) — zero recall on a common test/namespacing pattern #578), this loop had no findPythonModuleFile fallback — so it silently produced no edge for any direct (non-member) call through an absolute-module import, aliased or not.
  2. Even once the file resolved, findExportedSymbol filters candidates on n.isExported — and the Python extractor never implemented isExported, so it was undefined/falsy for every Python symbol. This normally went unnoticed because an unaliased call (from mod import summarize; summarize()) still resolves via unrelated same-name fuzzy matching when the name is globally unique — but an aliased direct call has no name to fuzzy-match on, so this generic import path was its only route, and it always failed.

Found on a real project (from scripts.lire_fec import summarize as fec_summary, called as fec_summary()).

Fix

Test plan

  • Added a regression test for a direct call through an aliased function import from an absolute dotted module path
  • Full test suite green: 2752 passed, 175 skipped, 0 failed

… imports

Two compounding gaps in `from mod import fn as alias; alias()`:

1. resolveViaImport's generic "reference name matches an import" loop
   resolved `imp.source` through resolveImportPath, which for Python
   only maps RELATIVE dotted paths (`.mod`, `..pkg.mod`). An ABSOLUTE
   dotted source (`from scripts.lire_fec import ...`) returned null
   there, and unlike resolvePythonModuleMember / resolveModuleImportToFile
   (colbymchenry#578), this loop had no findPythonModuleFile fallback — so it
   silently produced no edge for any direct (non-member) call through
   an absolute-module import, aliased or not.

2. Even once the file resolved, findExportedSymbol filters candidates
   on `n.isExported` — and the Python extractor never implemented
   `isExported`, so it was undefined/falsy for every Python symbol.
   This normally went unnoticed because an unaliased call
   (`from mod import summarize; summarize()`) still resolves via
   unrelated same-name fuzzy matching when the name is globally
   unique — but an aliased direct call has no name to fuzzy-match on,
   so this generic import path was its only route, and it always
   failed. Python has no export syntax, so every module/class-level
   def is importable by name; isExported is now false only for names
   nested inside a function body (closures).

Found via a real project (`from scripts.lire_fec import summarize as
fec_summary`, called as `fec_summary()`).
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.

1 participant