Skip to content

[repo-assist] refactor: replace O(n) children scans with O(1) firstNamedChild/childForFieldName lookups#427

Draft
github-actions[bot] wants to merge 1 commit into
mainfrom
repo-assist/improve-o1-child-scans-20260628-15f6c572679a91a2
Draft

[repo-assist] refactor: replace O(n) children scans with O(1) firstNamedChild/childForFieldName lookups#427
github-actions[bot] wants to merge 1 commit into
mainfrom
repo-assist/improve-o1-child-scans-20260628-15f6c572679a91a2

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

🤖 This PR was created by Repo Assist, an automated AI assistant.

Summary

Replaces the remaining linear .some()/.find() scans over node.children with O(1) tree-sitter field-access alternatives across three language analyzers. These hot paths run on every keystroke in the VS Code CodeLens provider, so reducing per-node allocation and iteration has a direct latency benefit.

Changes

goAnalyzer.ts

  • hasLabel(): node.children.some(c => c.type === "label_name")node.firstNamedChild?.type === "label_name"
    In Go's AST, label_name is the only named child of a labeled break/continue, so firstNamedChild gives an O(1) membership test.
  • pointer receiver type extraction: typeNode.children.find(c => c.type === "type_identifier")typeNode.firstNamedChild with a type check
    pointer_type has exactly one named child (the pointee type), so firstNamedChild avoids the linear scan.

rustAnalyzer.ts

  • hasLabel(): node.children.some(c => c.type === "label" || c.type === "loop_label")firstNamedChild?.type equality check
    Rust break_expression/continue_expression nodes have the loop label as their first (and only) named child.
  • getComplexityReason() else_clause case: .some(c => c.type === "if_expression")node.firstNamedChild?.type === "if_expression"
    The first named child of an else_clause is either an if_expression (else-if) or a block (plain else).

jsLikeAnalyzer.ts

  • getComplexityIncrement() break_statement/continue_statement: .some(c => c.type === "statement_identifier")node.firstNamedChild?.type === "statement_identifier"
    JS/TS labeled break/continue have statement_identifier as their only named child.
  • getComplexityReason() else_clause case: .some(c => c.type === "if_statement")node.firstNamedChild?.type === "if_statement"
    Same pattern as Rust above.
  • getFunctionName() pair key extraction: parent.children.find(c => c.type === "property_identifier" || c.type === "identifier")parent.childForFieldName("key") with type guard
    tree-sitter-javascript exposes the key field on pair nodes; childForFieldName is O(1) and more clearly expresses the intent.

Test Status

npm run compile  ✅  (0 errors)
npm run lint     ✅  (0 warnings)
npm run test:unit  ✅  159 passing, 0 failing

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

  • releaseassets.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "releaseassets.githubusercontent.com"

See Network Configuration for more information.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@5d1811880f4e924f367e64502f3c5870742892a3

…ForFieldName lookups

Replace linear .some()/.find() scans over node.children with O(1) alternatives
in Go, Rust, and JS/TS analyzers:

- goAnalyzer: hasLabel() uses firstNamedChild?.type instead of children.some()
- goAnalyzer: pointer_type inner type uses firstNamedChild instead of children.find()
- rustAnalyzer: hasLabel() uses firstNamedChild?.type instead of children.some()
- rustAnalyzer: getComplexityReason() else_clause uses firstNamedChild?.type
- jsLikeAnalyzer: labeled break/continue uses firstNamedChild?.type
- jsLikeAnalyzer: else_clause reason uses firstNamedChild?.type
- jsLikeAnalyzer: pair key lookup uses childForFieldName('key') for semantic clarity

All 159 unit tests pass.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants