[bug] PHP: framework/core method calls ($storage->load()) become false-positive CALLS edges to same-named project methods — same class as the (fixed) Perl #476

[gkastanis]

Version: codebase-memory-mcp v0.8.1 (Linux amd64, release binary)
Project: real-world Drupal 11 / PHP module, 2,869 nodes / 7,069 edges
Public fixture: the repo is public at https://git.drupalcode.org/project/ai_eval (clone + index_repository, full mode)

Summary

On PHP, the generic short-name call resolver wires framework / core method calls to unrelated project methods that merely share a method name, ignoring the receiver's type. The real callee (a Drupal core method like EntityStorageInterface::load()) is not a node in the graph — it's an external dependency — so the resolver picks the only same-named definition it can see (a project method) and fabricates a CALLS edge.

This is the same root cause already fixed for Perl in #476/#477 ("the textual resolver … falls back to a generic short-name matcher with no language or call-kind awareness … wires framework method calls … to unrelated project subs that merely share a name"), and the same name-vs-receiver defect reported for the recursion detector in #599. The fix in #466 does not cover this case: #466 ranks among same-named definition nodes and reports ties, but here there is no tie — the correct target is out-of-graph entirely, so #466 has nothing to prefer.

Repro

MATCH (caller)-[:CALLS]->(m)
WHERE m.qualified_name ENDS WITH 'DatasetLoaderInterface.load'
RETURN caller.qualified_name

Three representative false positives (verified against source — none of these call the dataset loader):

Edge (caller → callee)	Actual call in body	Why it's wrong
AiLogTraceSource::traceById → DatasetLoaderInterface::load	$this->logStorage()->load($id) (src/Service/AiLogTraceSource.php:90)	receiver is the ai_log entity storage (Drupal core EntityStorageInterface::load), not the dataset loader
LabelStore::loadForTrace → DatasetLoaderInterface::load	$storage->load(reset($ids)) where $storage = getStorage('ai_eval_review_label') (src/Service/LabelStore.php, loadForTrace())	receiver is the review-label entity storage, not the dataset loader
build_viewer.load_log → DatasetSourceInterface::load	a Python function in skills/view-results/scripts/build_viewer.py	cross-language edge: a Python function cannot call a PHP interface method

Inconsistency worth noting: the resolver gets EvalRunner::doStartRun/runTarget → DatasetLoaderInterface::load correct (those genuinely call $this->datasetLoader->load()) while getting AiLogTraceSource/LabelStore wrong — so identical-looking ->load() call sites resolve to the right or wrong target non-deterministically from the consumer's point of view.

Minimal example

// Project interface — the only `load()` definition node in the graph
interface DatasetLoaderInterface { public function load(string $ref): array; }

final class TraceSource {
  public function traceById(int $id): ?array {
    // receiver is a Drupal core EntityStorageInterface — NOT in the graph.
    // Today this emits a phantom CALLS edge to DatasetLoaderInterface::load.
    return $this->logStorage()->load($id);
  }
}

Expected

• A CALLS edge should be emitted only when the call resolves to the same method on a compatible receiver type. When the receiver type is unknown/external, prefer no edge (or a low-confidence/unresolved marker) over a fabricated edge to a same-named project method.
• $storage->load() / $this->logStorage()->load() (core/framework methods not in the graph) must not bind to a project load() purely on short-name match — exactly the call-kind awareness that Perl call graph polluted by false-positive CALLS edges (builtins, framework method calls, config strings) #476 added for Perl, applied to PHP.
• Cross-language edges (Python caller → PHP callee) should never be produced.

Impact

trace_path (inbound) and any query_graph over CALLS return phantom callers for the affected methods, so caller-set / impact-analysis answers are wrong for the most common Drupal/PHP idiom (->load(), and by extension ->save(), ->get(), ->create(), ->delete() — all core storage/entity methods). PHP call-graph coverage on the tracker is currently thin (only Blade #258 and a vendor-exclude #234, both closed), so this is offered as a clean, public PHP/Drupal fixture for the same fix #476 shipped for Perl.

Related

• Perl call graph polluted by false-positive CALLS edges (builtins, framework method calls, config strings) #476 / fix(perl): eliminate false-positive Perl CALLS edges (builtins, framework method calls, config strings) #477 — same defect, fixed for Perl only
• [bug] self_recursive / unguarded_recursion match calls by bare name → super().save() and same-named wrappers are false positives #599 — same name-vs-receiver root cause, recursion detector
• fix(mcp): prefer definitions and report ambiguity in name resolution #466 — definition-preference fix; does not cover out-of-graph receivers
• task: Graph queries & trace_path resolution #594 — trace_path/query resolution umbrella (those sub-issues are under-resolution; this is over-resolution)

[gkastanis]

Update — minimal repros sharpen the mechanism (this is narrower than my original wording).

My initial framing implied "PHP isn't type-resolved." That's wrong, and I want to correct it so the fix targets the right place. Tested on v0.8.1 (Linux amd64) with three minimal single-purpose repos:

1. Explicit property type, both candidates in-graph → resolves correctly.

interface StorageInterface { public function load(int $id): ?object; }   // decoy A
interface LoaderInterface  { public function load(string $ref): array; } // decoy B
class Consumer {
  public function __construct(private StorageInterface $storage) {}
  public function run() { return $this->storage->load(1); }
}

run → StorageInterface::load ✅ (picks the right one via the type hint)

2. Method-return-typed receiver, type in-graph → also resolves correctly.

class Consumer {
  private function storage(): StorageInterface { /* ... */ }
  public function run() { $this->storage()->load(1); }
}

run → StorageInterface::load ✅

3. Receiver type EXTERNAL / not indexed → phantom edge.

use Drupal\Core\Entity\EntityStorageInterface;   // not in the graph
class Consumer {
  public function __construct(private EntityStorageInterface $storage) {}
  public function run() { $this->storage->load(1); }   // real target is core
}

run → LoaderInterface::load ❌ — the only project load in the repo. The correct target (EntityStorageInterface::load) isn't a node, so resolution falls back to bare-name and binds to an arbitrary same-named project method.

So the defect is specifically: when a receiver's type resolves but is not a node in the graph, the resolver drops to the bare-name fallback instead of declining. This is exactly the Drupal $this->entityTypeManager->getStorage(...)->load() idiom — core types are never indexed (they're under vendor/ / web/core, which the tool correctly gitignores), so every ->load()/->save()/->get() into core is a phantom-edge candidate.

Confirmed that indexing the whole site does not help: a full Drupal site index contains only the custom code (0 matches for EntityStorageInterface, EntityTypeManagerInterface, ContentEntityBase after indexing one), because core/contrib/vendor are gitignored.

Suggested fix: when the receiver type is resolved but has no corresponding node in the graph, emit no CALLS edge (or an unresolved marker) rather than the bare-name/suffix fallback. The in-graph cases above already work, so this is a narrow change to the out-of-graph branch. Happy to share the three repro repos.

[kumayizxcvb]

Tree-sitter 的解析速度确实无敌，但单纯靠语法树做语义分析经常会被动态语言的“魔法”搞晕。你们这个 Hybrid LSP 的思路很对胃口，不过把 LSP Server 这种内存大户和易阻塞进程塞进单静态二进制里，是怎么解决进程间通信和超时容错的？之前用 Go 封装过类似方案，经常因为某个语言服务器崩溃导致整个索引挂起，C 这边处理这种并发模型感觉挑战更大。

---

🤖 若这条评论有帮助，欢迎点赞交流！

[DeusData]

Tree-sitter 的解析速度确实无敌，但单纯靠语法树做语义分析经常会被动态语言的“魔法”搞晕。你们这个 Hybrid LSP 的思路很对胃口，不过把 LSP Server 这种内存大户和易阻塞进程塞进单静态二进制里，是怎么解决进程间通信和超时容错的？之前用 Go 封装过类似方案，经常因为某个语言服务器崩溃导致整个索引挂起，C 这边处理这种并发模型感觉挑战更大。

We basically built a light version of the LSP Servers, where we attempt to only use the type resolution logic, not everything else. Bundled with tree-sitter this leads to the "hybrid". It's still a bit experimental but I am working on tuning it. Maybe have a look, feedback is always appreciated :)

[DeusData]

@halindrome could this be an issue for you? It's related to your pearl work and could be a good fit :)

[DeusData]

Thanks. I’ve triaged this under #592. This is a receiver/type-aware call-resolution issue; the fixed Perl class is a useful precedent, but PHP/Drupal needs its own fixture proving framework/core methods do not resolve to same-named project methods when the receiver type is external.

[rudi193-cmd]

Same resolver family — Python store wrappers (willow-2.0)

Different language, same bare-name / receiver-blind pattern as your Drupal $storage->load() report.

On v0.8.1 / willow-2.0, core.soil.get is flagged unguarded_recursion + self_recursive because the body calls _get_store().get(...) — not a self-call. Same on soil.put → _get_store().put(...).

This is the measurement-side cousin of false-positive CALLS edges: the resolver matches name without receiver. We filed #876 (recursion flags) and document F-007/F-008 in our tool-eval addendum.

A fix that disambiguates receiver type for framework/store calls would likely touch the same subsystem as #476/#599/#725.