Unfortunately, this adds a new conflict to the parser - and I don't see a way around that. Could you have a look at your convenience, @maxbrunsfeld?

If I remove the conflict, these are the options provided by the builder:

Unresolved conflict for symbol sequence:

  php_tag  '#['  name  •  ','  …

Possible interpretations:

  1:  php_tag  '#['  (attribute  name)  •  ','  …
  2:  php_tag  '#['  (qualified_name  name)  •  ','  …

Possible resolutions:

  1:  Specify a higher precedence in `qualified_name` than in the other rules.
  2:  Specify a higher precedence in `attribute` than in the other rules.
  3:  Add a conflict for these rules: `qualified_name`, `attribute`

Relevant definition from documentation:

First, an attribute declaration is always enclosed with a starting #[ and a corresponding ending ]. Inside, one or many attributes are listed, separated by comma. The attribute name is an unqualified, qualified or fully-qualified name as described in Using Namespaces Basics. Arguments to the attribute are optional, but are enclosed in the usual parenthesis (). Arguments to attributes can only be literal values or constant expressions. Both positional and named arguments syntax can be used.

Note: I've not placed any restrictions on the parameter types, but allow parsing them to keep the parser simple. I assume any utility using the parser will handle this. Please correct me if that is a wrongful assumption and we should only parse strictly valid code (even though that might be tricky while supporting multiple PHP versions)

It seems like in the existing grammar, qualified_name matches any name, even if it isn't qualified. So would it work to simply only allow qualified_name inside of attribute (remove the choice that allows $.name to be used directly)?

Thanks for your guidance, that did indeed do the trick!

It does feels wrong to use a node named qualified_name to mean both qualified and unqualified, but I guess I'll try to address that later - if I find a suitable way.

Thanks again!

I agree; it'd be great to address that at some point.

Peculiarly, according to the specification it seems to be correct... I'll have to study how other PHP parsers solve that before proposing a solution