Bug: ObjC extractor — 4 bugs causing ~60% of relationships to be silently dropped

[JabberYQ]

Summary

Testing /graphify . on a pure Objective-C iOS project (12 files, ~1,125 words) revealed 6 bugs in the ObjC extractor that collectively cause ~60% of code-level relationships to be silently dropped.

Test repo structure:

Demo/
  AppDelegate.h/.m
  Product.h/.m
  ProductListViewController.h/.m
  ProductDetailViewController.h/.m
  AlertManager.h/.m
  main.m

Expected: @interface → inherits edges, [self method] → calls edges, self.product.name → property access edges, addTarget:action: → callback edges, @property NSArray<X*> * → references edges, +classMethod labeled correctly.
Actual: 37 nodes, 30 edges, 11 communities — but all calls edges are missing, .h files are extracted as C (0 ObjC edges), property accesses & target-action are invisible, generic property types are invisible, and class methods are mislabeled.

---

Bug 1: .h files dispatched to C extractor instead of ObjC extractor

Root cause: _DISPATCH mapping at extract.py:12210:

".h": extract_c,     # ← ObjC headers parsed as C!
".m": extract_objc,
".mm": extract_objc,

Impact: Every .h file in an ObjC project is parsed by extract_c, which doesn't understand @interface, @property, @protocol, or method declarations. The C extractor produces exactly 1 node (the file itself) and 0 edges.

What's lost per .h file:

• @interface Foo : Bar → no inherits edge
• <Protocol> conformance → no implements edge
• @property (strong) SomeType *prop → no references edge
• Method declarations → no nodes

Verification:

# extract_c on AppDelegate.h → 1 node, 0 edges
# extract_objc on AppDelegate.h → 5 nodes, 5 edges
#   (AppDelegate, UIResponder, UIApplicationDelegate, UIWindow
#    + inherits/implements/references edges)

Suggested fix: In the dispatch logic, detect ObjC .h files (by @interface content heuristic, or when sibling .m/.mm files exist) and route them to extract_objc.

---

Bug 2: walk_calls never matches — 0 calls edges for all ObjC projects

Root cause: walk_calls at extract.py:9403-9427 looks for selector and keyword_argument_list children inside message_expression nodes:

if child.type in ("selector", "keyword_argument_list"):

But tree-sitter-objc represents simple selectors as identifier, not selector:

# AST for [self setupUI]:
message_expression
  [                   "["
  identifier          "self"
  identifier          "setupUI"    ← type is "identifier", not "selector"
  ]                   "]"

Only compound selectors like [self tableView:tv cellForRowAtIndexPath:ip] produce keyword_argument_list.

Impact: Every [receiver selector] call in every .m file is invisible. The entire method-body second pass (lines 9399–9427) is effectively dead code for ObjC. No calls edges are ever produced.

Verification: Extracted 4 .m files with 11 method definitions, 0 calls edges. Confirmed [self setupUI], [self loadProducts], [self setupTableView], [Foo sharedInstance], [super viewDidLoad] all produce identifier selector nodes.

Suggested fix: Add "identifier" to the child type check, distinguishing receiver from selector (skip the first identifier, or check field names if tree-sitter-objc provides them):

if child.type in ("selector", "identifier", "keyword_argument_list"):

---

Bug 3: Generic/parameterized property types not extracted

Root cause: property_declaration handler at extract.py:9323-9332 only looks for type_identifier as a direct child of struct_declaration:

for s in sub.children:
    if s.type == "type_identifier":   # ← direct child only

But tree-sitter-objc wraps parameterized types in a generic_specifier node:

# @property NSArray<Product *> *products:
struct_declaration
  generic_specifier              ← NOT type_identifier!
    type_identifier: "NSArray"   ← nested one level deeper
    <
    type_name: "Product *"
    >
  struct_declarator: "*products"

Impact: Foundation generic collections (NSArray<X*>, NSDictionary<K,V*>, NSSet<X*>) and custom generic ObjC types are invisible. Only non-generic property types produce references edges.

Verification:

@property (nonatomic, strong) UITableView *tableView;      // ✅ extracted
@property (nonatomic, strong) NSArray<Product *> *products; // ❌ not extracted

Suggested fix: Also recurse into generic_specifier children when walking struct_declaration children.

---

Bug 4: Class methods (+) labeled as instance methods (-)

Root cause: method_definition handler at extract.py:9388 hardcodes the label prefix:

add_node(method_nid, f"-{method_name}", line)

Impact: + (instancetype)sharedInstance becomes -sharedInstance in the graph. Node IDs and method edges are correct, but labels are misleading — users cannot distinguish class methods from instance methods.

Suggested fix: Check the first child of the method node. tree-sitter-objc emits + or - as the first child:

prefix = "-"
for child in node.children:
    if child.type == "+":
        prefix = "+"
        break
add_node(method_nid, f"{prefix}{method_name}", line)

---

Bug 5: Method-body property access (self.product.name) not extracted

Root cause: walk_calls (extract.py:9403) only handles message_expression nodes. ObjC dot-syntax property access is a field_expression — a completely different AST node type with no handler anywhere in the extractor.

tree-sitter-objc produces for self.product.name:

assignment_expression
  field_expression: "self.product.name"
    field_expression: "self.product"
      identifier: "self"
      .: "."
      field_identifier: "product"
    .: "."
    field_identifier: "name"
  =: "="
  string_literal: "@\"hi\""

Impact: All property read/write via dot syntax inside method bodies is invisible. This includes self.product.name, self.view.backgroundColor, self.tableView.rowHeight — every property access that connects ViewControllers to their data and views. Only the static @property declaration (Bug 1/3) appears in the graph, not the actual usage.

Suggested fix: Add a field_expression handler in the method-body walker (similar to walk_calls) that emits accesses edges from caller method → field identifier → resolved type.

---

Bug 6: Compound message expressions + @selector() not captured

Root cause (6a): tree-sitter-objc flattens compound ObjC messages. Unlike simple [self foo] which wraps parts in a message_expression node, compound messages like [obj method:arg1 param2:arg2] have brackets and parts as direct siblings of the parent with no wrapper:

# Simple [self foo] — HAS message_expression wrapper:
expression_statement
  message_expression      ← wrapper exists
    [                     "["
    identifier            "self"
    identifier            "foo"
    ]                     "]"

# Compound [b addTarget:self action:@selector(onTap) forControlEvents:0]:
# NO message_expression wrapper at all!
[                         ← direct child of compound_statement
identifier: "b"
identifier: "addTarget"
:: ":"
identifier: "self"
identifier: "action"
:: ":"
selector_expression: "@selector(onTap)"
identifier: "forControlEvents"
:: ":"
number_literal: "0"
]                         "]"

Impact (6a): walk_calls only visits message_expression nodes → compound messages are never processed. Even if Bug 2 is fixed (adding "identifier" to the check), compound messages remain invisible because the parent node doesn't exist.

Root cause (6b): @selector(onTap) produces a selector_expression node with no handler. This is the mechanism for target-action, delegate callbacks, and notification handlers — the backbone of Cocoa/CocoaTouch event wiring.

Impact (6b): Target-action bindings (addTarget:action:), timer callbacks, gesture recognizer handlers, and notification selectors are all invisible. The graph can't trace UI event flow from button tap → handler method.

Verification:

// None of these produce any edges:
[self.buyButton addTarget:self action:@selector(onBuyButtonTapped) ...]
[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(tick) ...]
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(update) ...]

Suggested fix for 6a: Instead of only traversing message_expression, also handle ObjC [/] bracket pairs directly as compound message boundaries. Walk compound_statement children for bracket-delimited message sequences.

Suggested fix for 6b: Add a selector_expression handler that extracts the method name from @selector(xxx) and emits a registers-callback or target-action edge to the referenced method.

---

Summary of uncovered relationships

Source code pattern	Expected edge	Extracted?
@interface Foo : Bar in .h	inherits	❌ (Bug 1)
<Protocol> in .h	implements	❌ (Bug 1)
@property X *p in .h	references	❌ (Bug 1)
[self method] / [Foo method]	calls	❌ (Bug 2)
[obj method:arg1 param2:arg2]	calls	❌ (Bug 6a)
[[Foo alloc] init]	instantiates	❌ (Bug 2)
self.product.name	accesses	❌ (Bug 5)
addTarget:action:@selector(xxx)	target-action	❌ (Bug 6a+6b)
@property NSArray<X*> *p	references	❌ (Bug 3)
@property NSDictionary<K,V*> *p	references	❌ (Bug 3)
+ (void)classMethod	method (label wrong)	⚠️ (Bug 4)
@interface Foo : Bar in .m	inherits	✅
@property X *p in .m extension	references	✅ (non-generic only)
<Protocol> in .m extension	implements	✅
#import "X.h"	imports	✅
@implementation Foo	contains	✅
- (void)method definition	method (label correct)	✅

[safishamsi]

Thanks for an exceptionally good report — the test repo, the expected-vs-actual counts, and the per-bug AST shapes made this fast to verify and fix. I validated each bug against the real tree-sitter-objc grammar before touching anything. Fixed on v8 in 8994b55:

• Bug 1 (.h → C extractor): confirmed (ObjC header gave 1 node/0 edges via the C extractor). A .h is now routed to the ObjC extractor when it contains an ObjC-only directive (@interface/@protocol/@implementation/@import). Those tokens are illegal in C/C++, so a genuine C/C++ header is never hijacked — verified a plain C and a C++ header both stay on their existing extractor.
• Bug 2 (no calls edges): confirmed. One adjustment to your suggested fix: adding "identifier" to the type check would also match the receiver (self/super/a class name) and mint false calls edges. tree-sitter-objc tags selector parts with the field name method, so I reconstruct the selector from the method fields and skip receiver — robust, and it makes compound sends resolve too.
• Bug 6a (compound messages): the symptom was real but the claimed mechanism isn't — there is a message_expression wrapper for compound sends (I dumped the AST); the parts are just method-field children. So the Bug 2 fix covers compound messages with no special-casing.
• Bug 3 (generic property types): confirmed and fixed — NSArray<Product *> * now references both the element type (Product) and the container.
• Bug 4 (class method label): confirmed — +foo was labeled -foo; now reads the +/- sigil.
• Bonus: @import Foundation; (a module_import node, which had no handler) now produces an imports edge.

Added six regression tests; full suite green, no C/C++ regressions.

Still open as follow-ups (they need a name/type-resolution policy to avoid flooding false edges, so I didn't rush them):

• Bug 5 — dot-syntax property accesses (self.product.name): a field_identifier carries no type, so naive name-matching would create many false edges. Likely scope: resolve self.<prop> against the current class's own declared properties.
• Bug 6b — @selector(...) target-action edges: similar name-resolution caution.

Leaving this open to track those two. Thanks again — this was a model bug report.

[safishamsi]

Update: the five fixes (the .h dispatch, calls edges incl. compound selectors, generic property types, +/- class-method labels, and @import) shipped in 0.8.50 — pip install -U graphifyy. Verified live in a real pipeline run. Keeping this open to track the two follow-ups: dot-syntax property accesses (Bug 5) and @selector(...) target-action edges (Bug 6b), which need a name/type-resolution policy first. Thanks again for the report.

[JabberYQ]

Thanks for the detailed response and the quick turnaround on the fixes — really appreciate it.

Tested on v0.8.50 against the same 12-file ObjC demo repo.

Fixed ✅

• Bug 2 (calls edges): Confirmed working. Now getting 7 calls edges, including ObjC-originated ones (ProductDetailViewController.m:L40 → setupUI, ProductListViewController.m:L27-28 → loadProducts / setupTableView). Was 0 before.
• Bug 3 (generic property types): Confirmed. @property NSArray<Product *> *products (L15) now produces two references edges — one to NSArray and one to Product. Both the container and element type are captured.
• Bug 4 (class method label): Confirmed. +showConfirmAlertForProduct:fromViewController: now correctly labeled with +.
• Bug 6a (compound messages): Confirmed fixed as part of Bug 2. Compound selectors produce calls edges.

Partially fixed ⚠️

• Bug 1 (.h dispatch): The routing itself works — files with @interface are no longer sent to the C extractor. However, 3 of 5 .h files in the test repo still produce no class entities:

  File	Result
  AppDelegate.h	✅ AppDelegate + inherits/implements/references edges
  ProductListViewController.h	✅ ProductListViewController + inherits UIViewController
  AlertManager.h	❌ only imports UIKit, no class node
  ProductDetailViewController.h	❌ only imports UIKit, no class node
  Product.h	❌ no edges at all

  Source files for comparison:

  ✅ AppDelegate.h (works)

  #import <UIKit/UIKit.h>
  
  @interface AppDelegate : UIResponder <UIApplicationDelegate>
  
  @property (nonatomic, strong) UIWindow *window;
  
  @end

  ✅ ProductListViewController.h (works)

  #import <UIKit/UIKit.h>
  
  @interface ProductListViewController : UIViewController
  
  @end

  ❌ AlertManager.h (fails)

  #import <UIKit/UIKit.h>
  
  @class Product;
  
  NS_ASSUME_NONNULL_BEGIN
  
  @interface AlertManager : NSObject
  
  + (void)showConfirmAlertForProduct:(Product *)product
                  fromViewController:(UIViewController *)viewController;
  
  @end
  
  NS_ASSUME_NONNULL_END

  ❌ ProductDetailViewController.h (fails)

  #import <UIKit/UIKit.h>
  
  @class Product;
  
  NS_ASSUME_NONNULL_BEGIN
  
  @interface ProductDetailViewController : UIViewController
  
  - (instancetype)initWithProduct:(Product *)product;
  
  @end
  
  NS_ASSUME_NONNULL_END

  ❌ Product.h (fails)

  #import <Foundation/Foundation.h>
  
  NS_ASSUME_NONNULL_BEGIN
  
  @interface Product : NSObject
  
  @property (nonatomic, assign) NSInteger productId;
  @property (nonatomic, copy)   NSString *name;
  @property (nonatomic, assign) double price;
  @property (nonatomic, copy)   NSString *productDescription;
  @property (nonatomic, copy)   NSString *imageName;
  
  - (instancetype)initWithId:(NSInteger)productId
                        name:(NSString *)name
                       price:(double)price
                description:(NSString *)description
                   imageName:(NSString *)imageName;
  
  @end
  
  NS_ASSUME_NONNULL_END

  The two working files share a pattern: no NS_ASSUME_NONNULL_BEGIN, no @class forward declarations. My guess is that tree-sitter-objc emits an identifier/macro_invocation node for NS_ASSUME_NONNULL_BEGIN that the class-entity handler doesn't walk past, so the @interface that follows is never reached — even though the file is now correctly routed to extract_objc.

Still open (as expected) ❌

• Bug 5 (dot-syntax accesses): 0 accesses edges.
• Bug 6b (@selector target-action): 0 target-action edges.

Overall: node count went from 37 → 63, edge count from 30 → 83. The calls, generic-type, and label fixes are the biggest wins. The NS_ASSUME_NONNULL_BEGIN issue is the main residual — happy to dig into the tree-sitter AST dump if that helps narrow it down.

[JabberYQ]

🆕 Additional Findings: ObjC Extractor — 3 New Bugs

Same test repo (ProductDemoList-OC, 12 files). Did a full source → graph.json edge audit. These 3 are outside the existing Bug 1–6 scope.

---

New Finding 1 — .m-file #import selectively dropped

Bug 1 covers .h files being routed to the C extractor, but .m files (ObjC extractor path) have their own #import issue: only Product.h is recognized; all other project headers are silently dropped.

// ===== Hit (4/4) =====
#import "Product.h"    // AlertManager.m               ✅
#import "Product.h"    // ProductListViewController.m   ✅
#import "Product.h"    // ProductDetailViewController.m ✅
#import "Product.h"    // Product.m                     ✅

// ===== Miss (0/4) =====
#import "ProductListViewController.h"   // AppDelegate.m               ❌
#import "ProductDetailViewController.h" // AlertManager.m              ❌
#import "AlertManager.h"               // ProductListViewController.m  ❌
#import "AppDelegate.h"                 // main.m                      ❌

4/4 hit vs 0/4 miss is not random. Likely walk_imports or import-path normalization deduplicates by filename, keeping only the first match.

---

New Finding 2 — Project-class cross-file alloc/init dropped

alloc/init of project classes inside method bodies produces zero edges:

// AppDelegate.m:15  ← app launch chain entry point
ProductListViewController *listVC = [[ProductListViewController alloc] init];  ❌

// AlertManager.m:32  ← alert confirm → push detail page
ProductDetailViewController *detailVC =
    [[ProductDetailViewController alloc] initWithProduct:product];            ❌

Not fully covered by Bug 2 (walk_calls selector type mismatch). Even after Bug 2 is fixed, upstream Bug 1 (.h→C) + New Finding 1 (import dropped) mean symbols like ProductListViewController never enter the symbol table, so reference resolution still fails. This is a triple-stack: Bug 1 + NF1 + Bug 2.

---

New Finding 3 — UIKit references edges actually come from @property declarations; alloc/init statements contribute zero

Within the same .m file, there is a clean dividing line between what @property captures and what [[Foo alloc] init] captures:

// ProductListViewController.m
@property (nonatomic, strong) UITableView *tableView;       // ✅ references UITableView
@property (nonatomic, strong) NSArray<Product *> *products; // ✅ references NSArray

// Same file, local variables only:
UIBarButtonItem *btn = [[UIBarButtonItem alloc] ...];       // ❌ no references edge
UITableViewCell *cell = [tableView dequeueReusableCell...]; // ❌ no references edge

// AppDelegate.m
@property (nonatomic, strong) UIWindow *window;             // ✅ references UIWindow

// Same file, local variable only:
UINavigationController *nav =
    [[UINavigationController alloc] initWithRootViewController:...];  // ❌ no references edge

Zero counterexamples: every class that appears only as a local variable has no references edge. Every class used as a @property type has one. The references edges come from property_declaration → type_identifier; alloc/init statements need their own handler.

---

Causal chain

Bug 1 (.h→C)  +  NF1 (import selectively dropped)
              ↓
       Project-class symbol table collapses
              ↓
   NF2 (alloc/init symbols unresolvable)
   NF3 (alloc/init statement has no handler)
   Bug 2    (walk_calls dead code)
   Bug 5    (field_expression no handler)
   Bug 6    (compound msg + @selector no handler)
              ↓
    AppDelegate ↔ ProductListViewController ↔ AlertManager
              ↔ ProductDetailViewController
    A complete call chain in source code, zero edges in the graph

Here is my test demo: ProductDemoList-OC.zip

[safishamsi]

Fixed all three of the residual/new findings on v8 (1652dad). Thanks again for the precise repro and the test repo — I verified each against the real tree-sitter-objc AST before touching anything.

1. .h files with NS_ASSUME_NONNULL_BEGIN produced no class node. Root cause turned out to be different from the walk-skips-a-wrapper hypothesis: tree-sitter-objc can't expand the argument-less NS_ASSUME_NONNULL_BEGIN macro (no trailing ;), and its presence before @interface makes the parser fail to emit a class_interface node at all — the whole interface gets swallowed into ERROR nodes. Fix: blank NS_ASSUME_NONNULL_BEGIN/END to equal-length spaces before parsing (offsets/line numbers preserved; macro-free files unchanged). One correction to your notes: @class Product; on its own does not break parsing — only the macro does. AlertManager.h, ProductDetailViewController.h, and Product.h now all produce their class nodes + inherits edges.

2. .m #import edges dropped. Not a dedup-by-filename — a path-resolution issue. The quoted import targeted the bare stem (product), but once a .h/.m pair exists the file ids get salted apart by path (product_h_product / product_m_product), so the bare-stem target no longer matched and the edge dangled. Fix: resolve the include to a real file and repoint import edges to the header variant during disambiguation, so a .m importing its own .h lands on the header instead of self-looping. All your project-header imports resolve now (and it fixed the same latent bug for C #include too).

3. [[Foo alloc] init] produced no edge. Confirmed — walk_calls only reconstructed selectors and skipped the receiver. It now emits a references edge from the allocating method to the class, resolved only when exactly one class of that name exists (so unknown/ambiguous names don't create false edges). The alloc/init cross-file references resolve now that #1 makes the class nodes exist. I deliberately shipped only the references edge and not a calls-to-init edge for now — init selectors are ambiguous across classes and would risk false edges.

Full suite green, with new regression tests (incl. a self-loop guard on the import edges).

Keeping this open to track the two still-deferred items, which both need a name/type-resolution policy first: Bug 5 (dot-syntax property accesses, self.product.name) and Bug 6b (@selector(...) target-action edges). Thanks again — this has been a model bug report.

[JabberYQ]

Thanks for the fixes! Re-tested on v0.9.2 against the same ProductDemoList-OC repo (12 files).

✅ Confirmed fixed (the three from 1652dad)

1. .h files with NS_ASSUME_NONNULL_BEGIN now produce class nodes. AlertManager.h, ProductDetailViewController.h, and Product.h all emit their class node now, each with the correct inherits edge (→ NSObject / → UIViewController). Previously these 3 gave nothing.
2. .m #import of project headers now resolves. All 12 import edges are present, including the four that were dropped before: AppDelegate.m → ProductListViewController.h, AlertManager.m → ProductDetailViewController.h, ProductListViewController.m → AlertManager.h, main.m → AppDelegate.h.
3. Cross-file [[Foo alloc] init] now emits references edges. -application:didFinishLaunchingWithOptions: → ProductListViewController (L15), +showConfirmAlertForProduct:fromViewController: → ProductDetailViewController (L32), and -loadProducts → Product (L71) all resolve as EXTRACTED.

Counts went 37/30 (pre-fix) → 63/83 (0.8.50) → 65 nodes / 76 edges now. 👍

⏳ Still deferred (as expected)

1. Bug 5 — dot-syntax property accesses (self.product.name): 0 accesses edges.
2. Bug 6b — @selector(...) target-action (@selector(onCollectButtonTapped)): 0 target-action edges.

🆕 New issue: cross-class class-method (+) sends produce no calls edge

The Bug 2 fix resolved intra-class [self method] sends (I get 4 calls edges like -viewDidLoad → -setupTableView). But a cross-file send to a class method produces no calls edge at all.

Call site — ProductListViewController.m:145 (inside -tableView:didSelectRowAtIndexPath:):

Product *product = self.products[indexPath.row];
[AlertManager showConfirmAlertForProduct:product fromViewController:self];

Target — AlertManager.m:12:

+ (void)showConfirmAlertForProduct:(Product *)product
                fromViewController:(UIViewController *)viewController {

Expected: -tableView:didSelectRowAtIndexPath: --calls--> +showConfirmAlertForProduct:fromViewController: (or at least … --calls--> AlertManager).
Actual: 0 calls edges touch AlertManager or +showConfirmAlertForProduct:fromViewController:. Its only inbound edges are contains / method / inherits / imports. So ProductListViewController → AlertManager is only connected via the imports edge — the method-level call hop is missing.

For contrast, the equivalent type-qualified static call in the Swift demo (AlertManager.showConfirmAlert(...)) does resolve to a calls edge (EXTRACTED 1.0), so the gap looks specific to ObjC class-method (+) message sends across files. Happy to share an AST dump if useful.