Summary
GitGalaxy's apex func_start regex (gitgalaxy/standards/language_standards.py, apex rule
block) misidentifies new ClassName(...) object-instantiation expressions as function/method
definitions when the new keyword sits at the start of a source line -- a common shape in
multi-line SObject-builder calls, e.g.:
Account acct = (Account) TestFactory.createSObject(
new Account(name = 'Original Name'),
true
);Line 2 above (new Account(name = 'Original Name'),) gets matched as a function definition named
Account.
Root cause
The regex's optional return-type/modifier prefix group --
(?:[a-zA-Z_][\w.]*(?:generics)?(?:\[\])*\s+)? -- accepts any identifier-shaped token followed
by whitespace at the start of a line, with no exclusion list beyond the captured name itself
(class|interface|enum|if|for|while|switch|catch). new is a reserved instantiation keyword in
Apex, never a legitimate return type or modifier, but nothing excludes it from that prefix slot.
So new Account( parses as "return type = new, function name = Account" and passes the #1221
gating fix (which only requires the line start with some annotation/modifier/return-type-shaped
token, not that the token be a real one).
tree-sitter does not make this mistake: its Apex grammar structurally distinguishes
object_creation_expression from method_declaration.
Evidence
Discovered via the tri-comparison ledger
(apex/function/existence/agree[gitgalaxy]_vs[tree_sitter], 2 sampled occurrences,
AuraEnabledRecipes_Tests.cls:25 and :43). Confirmed by direct source read and by running the
regex standalone against the whole language-crucible/data/apex corpus, which surfaces the same
shape 6 times across 2 files:
apex-recipes/AuraEnabledRecipes_Tests.cls:6,25,43 -- new Account(...)apex-recipes/SOQLRecipes_Tests.cls:226,235 -- new Account(...)apex-recipes/SOQLRecipes_Tests.cls:504 -- new Opportunity(...)
All 6 are multi-line constructor-call arguments, none are real method/constructor definitions.
Suggested fix
Exclude new from the optional return-type/modifier prefix group in the apex func_start (and
likely args, which shares the identical prefix shape) regex -- e.g. a negative lookahead
(?!new\b) immediately before that group, so new can never be consumed as a pseudo return type.
Ledger
Tracked as validated in docs/self_scan/tri_comparison_ledger.json under
apex/function/existence/agree[gitgalaxy]_vs[tree_sitter] -- see that entry's verdict for the
full investigation writeup.
Summary
GitGalaxy's apex
func_startregex (gitgalaxy/standards/language_standards.py, apex ruleblock) misidentifies
new ClassName(...)object-instantiation expressions as function/methoddefinitions when the
newkeyword sits at the start of a source line -- a common shape inmulti-line SObject-builder calls, e.g.:
Line 2 above (
new Account(name = 'Original Name'),) gets matched as a function definition namedAccount.Root cause
The regex's optional return-type/modifier prefix group --
(?:[a-zA-Z_][\w.]*(?:generics)?(?:\[\])*\s+)?-- accepts any identifier-shaped token followedby whitespace at the start of a line, with no exclusion list beyond the captured name itself
(
class|interface|enum|if|for|while|switch|catch).newis a reserved instantiation keyword inApex, never a legitimate return type or modifier, but nothing excludes it from that prefix slot.
So
new Account(parses as "return type =new, function name =Account" and passes the #1221gating fix (which only requires the line start with some annotation/modifier/return-type-shaped
token, not that the token be a real one).
tree-sitter does not make this mistake: its Apex grammar structurally distinguishes
object_creation_expressionfrommethod_declaration.Evidence
Discovered via the tri-comparison ledger
(
apex/function/existence/agree[gitgalaxy]_vs[tree_sitter], 2 sampled occurrences,AuraEnabledRecipes_Tests.cls:25and:43). Confirmed by direct source read and by running theregex standalone against the whole
language-crucible/data/apexcorpus, which surfaces the sameshape 6 times across 2 files:
apex-recipes/AuraEnabledRecipes_Tests.cls:6,25,43--new Account(...)apex-recipes/SOQLRecipes_Tests.cls:226,235--new Account(...)apex-recipes/SOQLRecipes_Tests.cls:504--new Opportunity(...)All 6 are multi-line constructor-call arguments, none are real method/constructor definitions.
Suggested fix
Exclude
newfrom the optional return-type/modifier prefix group in the apexfunc_start(andlikely
args, which shares the identical prefix shape) regex -- e.g. a negative lookahead(?!new\b)immediately before that group, sonewcan never be consumed as a pseudo return type.Ledger
Tracked as validated in
docs/self_scan/tri_comparison_ledger.jsonunderapex/function/existence/agree[gitgalaxy]_vs[tree_sitter]-- see that entry'sverdictfor thefull investigation writeup.