[AdamMagued]

Summary

Fix custom rule parsing when grouped rules use custom label names such as array_has_key: { ... }.

Problem

In custom rule definitions, grouping patterns under a labeled block failed unless the label started with any or seq. When a user defined a grouped rule block with any other label name (for instance, array_has_key: { ... } or always_true: { ... }), tryParseLabeledStmt returned false, nil. The parser treated array_has_key: as an independent rule pattern, registered a rule for ir.LabelStmt, and dropped the child patterns in the statement block.

When the linter encountered an ir.LabelStmt node, phpgrep attempted to match against the rule and panicked with:

unhandled node: x=*ir.LabelStmt y=*ir.LabelStmt (please, fill an issue on GitHub)

Changes

1. Rule parser (src/rules/parser.go): Default to parseAny mode for labeled blocks whose name does not begin with seq. All statements within labeled blocks parse as grouped rule patterns inheriting parent metadata.
2. AST matching (src/phpgrep/matcher.go): Handle *ir.LabelStmt and *ir.GotoStmt in eqNode to prevent unhandled node panics when evaluating code with labels or gotos.
3. Automated tests:
   • src/rules/parser_test.go: Add TestParser_GroupedRule verifying rule registration from the issue Grouped rule fails to parse #1241 reproducer.
   • src/tests/rules/multipattern_test.go: Add TestRuleGroupedBlock verifying end-to-end lint reports and label handling.
   • src/phpgrep/matcher_test.go: Add positive and negative match test cases for LabelStmt and GotoStmt.

Fixes #1241