PHP: method calls and plain function calls not extracted as CALLS edges

[kojiromike]

Summary

When building a graph on a large PHP codebase (~4,400 PHP files, 33K functions, 3K classes), the parser produces only 58 CALLS edges from PHP files. Method calls ($this->method(), $obj->method()), static calls (Class::method()), and plain function calls (sqlQuery(...), xl(...)) are not being captured.

CONTAINS and IMPORTS_FROM edges work well (36K and 12K respectively), so the file/class/function structure is there — but without call edges, blast-radius analysis is effectively disabled for PHP.

Reproduction

git clone https://github.com/openemr/openemr.git
cd openemr
uvx code-review-graph build
sqlite3 .code-review-graph/graph.db "SELECT kind, COUNT(*) FROM edges WHERE file_path LIKE '%.php' GROUP BY kind ORDER BY COUNT(*) DESC;"

Output:

CONTAINS|36770
IMPORTS_FROM|12401
CALLS|58

The 58 CALLS edges that do exist are all global function calls with a \ prefix — \dirname(), \is_array(), \is_null(), etc. Calls without the leading backslash, method calls, and static calls are all missing.

Expected

PHP call extraction should capture at minimum:

• Plain function calls: sqlQuery(...), xl(...), text(...)
• Method calls: $this->execute(...), $service->search(...)
• Static method calls: QueryUtils::fetchRecords(...), EncounterService::create(...)
• Scoped calls: parent::__construct(...), self::factory(...)

Tree-sitter's PHP grammar exposes these as function_call_expression, member_call_expression, scoped_call_expression, and nullsafe_member_call_expression node types, so the AST data is available.

Environment

• code-review-graph installed via uvx (latest from PyPI as of 2026-04-15)
• Target repo: openemr/openemr at commit a7a3f0a (4,770 files, 64,600 nodes)
• macOS, Python 3.12

Context

OpenEMR is a large open-source healthcare EHR. The PHP call extraction gap is the main blocker — the structural (CONTAINS) and import (IMPORTS_FROM) edges are already useful, but blast-radius analysis needs CALLS edges to be practical.

Related issues

• Add PHP support to language index #273 — "Add PHP support to language index" (filed against v2.2.1 when PHP wasn't parsed at all). As of v2.3.2, PHP files are parsed and nodes are created, but CALLS edges are still missing.
• Kotlin and Swift tree-sitter parsers do not emit CALLS edges (only CONTAINS/IMPORTS_FROM/INHERITS) #294 — Same symptom (zero CALLS edges) for Kotlin/Swift, fixed in v2.3.2. PHP appears to still have this gap in the same version.

[Bakul2006]

Hey @kojiromike Before digging deeper, I wanted to confirm — are call expressions (function calls, method calls like $obj->method(), and static calls like Class::method()) currently supported in the PHP parser?
Or is call extraction not yet implemented / limited for PHP?

[kojiromike]

Hey @Bakul2006 — I dug into this. Call expressions are configured but the name extractor doesn't handle PHP's tree-sitter child node types, so it silently returns None and skips the CALLS edge.

Where it's configured

PHP is listed in CALL_NODE_TYPES at line 278 with function_call_expression and member_call_expression. So tree-sitter does match these nodes during the walk. The problem is downstream.

Where it breaks

_get_call_name at line 3659 extracts the function/method name from the matched node. It checks first.type against patterns like identifier, member_expression, attribute, scoped_identifier, etc. — but PHP's tree-sitter grammar uses different child types for all three call forms:

Call form	PHP tree-sitter structure	What _get_call_name expects
plainFunc()	function_call_expression → child name	identifier
$obj->method()	member_call_expression → children variable_name, ->, name	member_expression or attribute wrapper
Class::method()	scoped_call_expression → children name, ::, name	scoped_identifier or qualified_name

Since name doesn't match identifier (line 3721), and the member/scoped wrappers don't match the member_types tuple (line 3742–3745), the method falls through to return None (line 3762) for every PHP call.

Verification

Here's the tree-sitter AST for PHP calls:

# $obj->method()
member_call_expression
  variable_name → $ → name("obj")
  ->
  name("method")
  arguments

# ClassName::staticMethod()
scoped_call_expression
  name("ClassName")
  ::
  name("staticMethod")
  arguments

# plainFunc()
function_call_expression
  name("plainFunc")
  arguments

The fix would need to add PHP-specific handling in _get_call_name, similar to what exists for Perl (line 3714), Kotlin, and Objective-C. Something like:

• For function_call_expression: check first.type == "name" and return its text
• For member_call_expression: find the name child after -> and return its text
• For scoped_call_expression: find the name child after :: and return its text (also needs to be added to CALL_NODE_TYPES)

Note that scoped_call_expression (Class::method()) is not listed in CALL_NODE_TYPES at all — only function_call_expression and member_call_expression are configured.

[Bakul2006]

Ok @kojiromike I just got the point Basically I have to define all the remaining call types which are not yet covered..
Also I should check the proper Matching of the Return type from all the three call forms..

[kojiromike]

@Bakul2006 would you like me to draft a PR?