Oh, nice! This is way less messy than I thought it would be.

I'd expect these to generate an n_INDEX_ACCESS node, similar to this rule:

object_dim_list '[' dim_offset ']' {
  $$ = NNEW(n_INDEX_ACCESS);
  $$->appendChild($1);
  $$->appendChild($3);
  NMORE($$, $4);
}

Is that crazy?

Also, can we remove this block (near line 2607) without effect / breaking tests? I think it's a vestigial effort to fix part of this issue from XHP, which was written before PHP changed the grammar:

// Fix the "bug" in PHP's grammar where you can't chain the [] operator on a
// function call.
// This introduces some shift/reduce conflicts. We want the shift here to fall
// back to regular PHP grammar. In the case where it's an extension of the PHP
// grammar our code gets picked up.
expr_without_variable:
  expr '[' dim_offset ']' {
    if (yyextra->idx_expr) {
      yyextra->used = true;
    }
    $$ = NNEW(n_INDEX_ACCESS);
    $$->appendChild($1);
    $$->appendChild($3);
    NMORE($$, $4);
  }
;

I would guess it is now redundant with these more-complete rules. If it can be removed, that probably leaves the "idx_expr" and "used" properties on yyextra unused.

Sure, I'll give it a try and see what happens. I was mostly jumping around the Zend grammar and adding in stuff that looked missing - I was wondering about that second definition of expr_without_variable. It would be great if removing it reduced some conflicts as the comment suggests; there are only three in zend_language_parser.y and this is up to fifteen now.