fix(python): resolve aliased from-import CALLS to real def

[Joseph-MingEn]

Summary

• Sequential build_import_map now uses resolve_import_node (not fqn_module on pkg.symbol paths) so from M import f as g lands in the import map.
• Absolute/relative from-import: when Strategy-1 lands on a Module/File but module_path names a member Function/Class, prefer the member as the IMPORTS target so bare alias calls can import_map to the real def.
• Regression / pins: relative + absolute aliased from-import CALLS contracts; ghost-module negative (from ghost_module import nope as alias; alias() → no CALLS); registry adversarial pin for def-QN-under-alias-key (behavior already on main via Python: CALLS / trace_path blind to import aliases (import scan_bash as _scan_bash) #875/fix(registry): resolve aliased direct-symbol imports in import_map (#875) #979 — comment-only registry.c).

Broader graph-shape note (maintainer call)

Plain and aliased from-imports share the same module_path ("M.f"), so the member-preference block retargets IMPORTS Module → member def for every Python from-import that resolves that way — not only aliases. That is more precise for from M import f, but it changes:

• module-dependency / file→Module IMPORTS expectations
• detect_changes impact propagation that walked Module IMPORTS
• any query assuming from-import always ends on Module

This is intentionally in front of the maintainer (same mechanism class as the ~11K-edge #1000 regression). Happy to split or gate if preferred.

Evidence (not Django-scale)

• Local: ./build/c/test-runner registry lang_contract → 97 passed (includes new ghost-module negative).
• Consumer lab (Yui BASIC, mid-size Python monorepo): after patched MCP + full re-index, trace_path(submit_task) hop-1 lands on services.satori_bridge.gate.execute without changing the import execute as bridge_execute alias in source. Graph after ≈ 11549 nodes / 46879 edges. No Django-scale before/after edge-count diff available from this contributor machine.

Test plan

• make -f Makefile.cbm lint-format (Homebrew LLVM clang-format)
• ./build/c/test-runner registry lang_contract — 97 passed
• CI lint + test (was skipped while lint failed) + ci-ok

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[Joseph-MingEn]

Rebased onto current DeusData/main and resolved conflicts in registry.c / test_registry.c:

• Kept upstream #875/#979/#1000 suffix-safe bare-alias direct hit (do not swallow .method suffix).
• Kept Yui-shaped resolve_import_map_aliased_from_import + absolute from-import member IMPORTS (pass_pkgmap) + lang_contract tests.
• Local: ./build/c/test-runner registry lang_contract → 96 passed.

Ready for CI when the merge queue picks this up.

[Joseph-MingEn]

Conflict recheck: rebased/force-pushed head b81c1e2. Local merge vs current main (69599b7) is a clean fast-forward (no conflict markers). If the UI still shows conflicts on registry.c / test_registry.c, please refresh mergeability — those were from the pre-rebase tip.

[DeusData]

Thank you for this — and welcome. Reviewed properly rather than skimmed, because the root cause you found is a good one.

The diagnosis is right and I verified it on main. cbm_pipeline_fqn_module → fqn_compute(name=NULL) → strip_file_extension() strips the last dot-segment unconditionally, so a Python from-import path pkg.mod.symbol collapses to the Module QN proj.pkg.mod. The alias then maps to the Module, a bare call builds the candidate moduleQN.g — a ghost — and resolves to nothing. Routing the sequential import map through cbm_pipeline_resolve_import_node, the same resolver the IMPORTS pass already uses, fixes the sequential and parallel legs at a single choke point. That is the right shape, and it is the right layer: pipeline base, below the LSP passes, so the hybrid-LSP work stays additive on top.

I also went looking for the failure mode that would make this dangerous — resolving to a same-named symbol in a different module — and it cannot happen. The member QN is built strictly inside the resolved module's namespace and must hit an existing node by exact QN with a targetable label, with Module and File excluded. Cross-module leakage is not reachable. Import maps are per-file, so the same alias in two files cannot collide either.

There is a nice side benefit too: from M import C; C.method() now direct-hits proj.M.C.method instead of leaning on the by-name suffix fallback, which could previously pick a different class's .method in the same module. That is a genuine accuracy win beyond the aliased case.

Two things need your hand, one trivial and one that needs the maintainer.

1. The lint failure is hiding something important. pass_pkgmap.c:1533-1534 has clang-format violations — your new import_last_segment(...) line break. Trivial in itself, but the consequence is not: because lint failed, the entire test job was auto-skipped, so your new contract tests have never actually run on CI, on any platform. The green pr-smoke checks make the PR look better-verified than it is.

Run make -f Makefile.cbm lint-ci locally to reproduce it. One caveat that will save you a wasted round trip: our clang-format is the Homebrew LLVM build — a standalone clang-format-20 produces spurious whole-file drift that looks nothing like the two real lines. Once that is fixed, CI will exercise your tests for the first time.

2. The change is wider than the title, and that part is the maintainer's call. Because plain and aliased from-imports store the same module_path ("M.f"), the member-preference block retargets the IMPORTS edge from the Module node to the member def for every Python from-import in every indexed repo — not just aliased ones. It is arguably more precise, and arguably what from M import f actually means. But it changes module-dependency queries, detect_changes impact propagation, and anything expecting file→Module IMPORTS edges.

That is a graph-shape decision rather than a bug fix, and it lands in the exact mechanism that once regressed about 11,000 edges (#1000), so I have put it in front of the maintainer instead of deciding it in review. Two things would help it along: state the broader effect explicitly in the PR description, and — if you are able — a before/after edge-count diff on a Django-scale repository. That evidence is what would derisk it.

One test I would like: a pure negative — from ghost_module import nope as alias; alias() must produce no CALLS edge at all. Your existing ghost-negative assertions cover the invented-alias case nicely; this would pin the unresolvable-module case too, which is the one where an over-eager resolver would invent an edge.

Smaller notes: the PR body says the change makes resolve_import_map prefer an exact registry hit, but that behaviour already exists on main and your registry.c diff is comment-only — the registry test is a useful adversarial pin rather than a regression test, worth relabelling. And the empty commit 345a350 is harmless; it disappears in a merge commit.

Fix the formatting and this gets a real CI run; I will come back to you on the IMPORTS-edge question either way.

[Joseph-MingEn]

Thanks for the careful review — addressed:

1. Lint / format: pass_pkgmap.c member-prefer block reformatted with Homebrew LLVM clang-format (make -f Makefile.cbm lint-format clean). Rebased onto current main.
2. Ghost-module negative: added contract_python_ghost_module_aliased_from_import_no_calls — from ghost_module import nope as alias; alias() must emit no CALLS. Local registry + lang_contract → 97 passed.
3. PR description: now states the broader Module→member IMPORTS retarget for all Python from-imports (not just aliases), and that this is a maintainer graph-shape call. Yui mid-size lab cited; no Django-scale edge-count diff from this machine.
4. Registry test: relabelled as adversarial pin (exact-hit behavior already on main; registry.c remains comment-only).

Please re-check once CI runs test (previously skipped behind lint). Happy to iterate on the IMPORTS-edge scope if you want it narrowed or gated.

[Joseph-MingEn]

CI note: the red test-unix (macos-15-intel) / ci-ok is unrelated to this PR’s Python alias / IMPORTS changes.

Failure site:

lock_registry_absolute_deadline_survives_repeated_wakes
FAIL tests/test_lock_registry.c:1153: ASSERT(tail_queued)

On that same job, lang_contract was 40/40 (incl. the new ghost-module negative). All other test-unix / Windows / tsan / lint / smoke matrices were green.

Re-running failed jobs now. If it flakes again we can wait for maintainer guidance or another rerun — not planning to touch lock_registry in this PR.

[DeusData]

Your diagnosis is correct, and you do not need to prove it — it is already on our list.

lock_registry_absolute_deadline_survives_repeated_wakes (tests/test_lock_registry.c:1153) is one of two tests in that suite that wait on a 500 ms observation window for waiters to park, and then assert against it. That is a transient-window assertion, which under our own testing doctrine is a defect in the test rather than a property of your change: a verdict that depends on how a shared runner is scheduled is not a verdict. Its sibling lock_registry_large_queue_parks_non_head_waiters (:897) has the same shape. Both fail preferentially on the slower macos-15-intel runner, which is exactly where yours failed.

So: not yours, and you were right not to touch lock_registry in this PR. A re-run may clear it, but please read that as a coin landing the right way rather than as evidence — the fix we owe is a seam or a held gate, not a wider budget. It is recorded for us to do.

Your PR itself is still with the maintainer for the graph-shape question raised earlier; that is a direction call, not a quality one, and nothing further is needed from you while it waits. Thank you for the clean triage — reporting the failing site with the surrounding evidence (lang_contract 40/40 on the same job, everything else green) is precisely what makes a CI report actionable.

[DeusData]

Thank you @Joseph-MingEn — and thank you especially for flagging the graph-shape consequence yourself instead of letting it land quietly. That is the part that decides this PR.

The alias fix is clearly right: from M import f as g followed by g() should reach the real def, and the ghost-module negative (from ghost_module import nope as alias → no CALLS) is exactly the control I would have asked for.

But as you say, the member-preference block retargets IMPORTS Module → member def for every Python from-import that resolves that way, not only aliased ones. That is more precise in isolation and it changes module-dependency shape, detect_changes impact propagation, and any query that assumes a from-import terminates on a Module. Your comparison to the ~11K-edge #1000 regression is apt, which is why I am not merging this on my own judgement — it is a direction call for the maintainer, and I have put it in front of him with your framing intact.

Your offer to split or gate is the likely path: the alias resolution could land now on its own merits, with the broader Module→member retarget as a separate, deliberate decision that gets a before/after edge-count comparison on a large repo. If he prefers that, would you be up for splitting it? If not, I will do the split myself and keep you as author on both halves.

Either way the work is not going to sit — it is in the active batch, just gated on one decision rather than on review.

[DeusData]

@Joseph-MingEn — the maintainer came back with a better option than the either/or I put to you, and I think it dissolves the direction question entirely.

Emit both edges instead of retargeting. Keep File → Module M, and add File → Function M.f, rather than replacing one with the other.

I checked that the graph can actually hold that: edge identity is source:target:type (plus local_name for IMPORTS), so the Module edge and the member edge have different keys and coexist naturally — no collision, and genuinely repeated imports still dedup on their own. IMPORTS already carries local_name, so the alias itself is modelled today.

What that buys, compared to retargeting:

• the alias call resolution you are after works the same way;
• module-dependency queries and detect_changes propagation over Module IMPORTS keep working, so the shape change that made this a maintainer call goes away;
• the risk becomes purely additive rather than semantic — nothing that works today stops working.

The cost is edge growth: one extra IMPORTS edge per from-import that resolves to a member, which on a Python-heavy repo is not nothing. Two things worth doing about that:

1. Mark the member edge with a distinguishing property so consumers counting IMPORTS for dependency metrics can filter it, instead of having to infer intent from the target's label.
2. Measure it. Your consumer-lab numbers (≈11549 nodes / 46879 edges) are a fine baseline — a before/after on the same repo would tell us the real multiplier, and that is the number that decides whether this needs gating.

Would you like to take that direction? If you would rather not rework it, say so and I will implement it with you as co-author — the analysis and the ghost-module control are the hard parts and they are already done.

Your instinct to flag the shape change rather than bury it is what made this outcome possible; a quieter PR would have shipped the regression.

[DeusData]

Correction to my previous comment, because I framed the edge growth wrongly and the maintainer pushed back on it.

I called the extra edges a "cost" to be measured before deciding whether to gate. That was over-cautious. These are true additions: from M import f really does import the symbol, and the graph has only ever recorded half of that relationship. And since the IMPORTS edge key includes local_name, repeated identical imports dedup on their own — so growth is bounded by the number of distinct (file, imported symbol) pairs, which is a real property of the codebase rather than an inflation factor.

An edge count that rises because the graph finally represents something true is this project working as intended, not a regression to be defended against. Graph quality comes first here.

So the proposal stands unchanged in shape, but without the gating implication:

• emit both edges (Module + member), no retargeting — nothing that works today stops working;
• mark the member edge so consumers counting IMPORTS for dependency metrics can distinguish a module dependency from a symbol import. That is a labelling concern, and it is the only real one left;
• record the before/after numbers on your consumer lab as the new baseline — useful to have, not a gate to pass.

Same offer as before: yours to take, or I implement it with you as co-author. And apologies for the mixed signal — the second read was better than my first.