fix(apex): match commas, spaces, and dots in method return types

[Fmahdavi]

Fixes #3217

Problem

method_re in the Apex extractor matches the return type with a single character class, [\w<>\[\]]+, which cannot contain a comma, space, or dot. Any method returning Map<String, Object>, Database.QueryLocator, List<Map<String, Id>>, or an inner/dotted type is silently dropped — no node, no edges, no warning. In practice that includes every Database.Batchable start() and the common @AuraEnabled Map<String, Object> controller pattern.

Fix

Replace the return-type token with a base token plus an optional generic group:

_RETTYPE = r"[\w.\[\]]+(?:\s*<[^;{}()=]*>)?"

Excluding ;{}()= inside <...> keeps non-signature lines from matching: declarations with initializers (Map<Id, X> m = new Map<Id, X>();), calls, and control flow all still fail to match, and the existing _CONTROL_FLOW name filter is unchanged.

Verification

• New regression test test_apex_method_generic_and_dotted_return_types fails on the old pattern, passes on the new one (fixture extended with the three shapes).
• All pre-existing apex tests pass (14/14 with the new one).
• Full tests/test_languages.py run produces an identical failure set with and without this change in my environment (pre-existing, unrelated to apex).
• Scanned against a 455-file production Salesforce codebase: the old pattern's match set is strictly contained in the new one (0 regressions), and 512 recovered lines are all genuine method signatures — none lacking a comma, dot, or generic in the return type.

🤖 Generated with Claude Code

[graphify-labs]

Graphify reviewed this change.

Looks safe to merge — no coupling regressions and no blocking issues, checked against the code graph (not a self-assessment).

Formal verification. No changes could be formally verified in this run.

---

Graphify review — findings

Fixes the Apex extractor dropping methods whose return type contains dots, spaces, commas, or nested generics — Map<String, Object>, Database.QueryLocator, and List<Map<String, Id>> return types are now matched via a dedicated _RETTYPE pattern instead of a single character class. Adds a regression test and fixture methods covering those cases.

No blocking issues surfaced. 2 lower-confidence candidates did not survive cross-model review.

Analysis details — impact, health, verification

Impact & health

Graphify review

Impact — 574 functions depend on the 574 functions this change touches.

Health — this change adds coupling hotspots:

• new: extract_apex() — 16 callers, 4 callees

Verification — 574 functions in the blast radius were not formally verified this run (proofs are advisory here).

Gate & verification

graphify gate

PASS — objectively clean (no health regressions, tests not run — proofs not run this pass (advisory)). Grounded, not self-assessed.

Advisory (not blocking):

• verification_scope: 574 function(s) in the blast radius were not formally verified this run

Formal verification

Could not verify: Could not verify extract\_apex.

The verifier did not have enough to check extract\_apex, so it is saying so rather than guessing. No false assurance is the whole point.

Guarantee: No guarantee either way, this is an honest abstention, not a pass.

Note: Reason: parameter `path` is annotated `Path` — outside the synthesizable primitive/collection set

· 1 more finding(s) on lines outside this diff (see the check run).