Skip to content

Conversation

@leonerd
Copy link
Contributor

@leonerd leonerd commented Nov 14, 2025

We need to use a dedicated grammar type; or at the very least, not use subattrlist for doing this. The previous use of subattrlist had the side-effect of passing every attribute list for a class via the apply_builtin_cv_attributes() function. That was pointlessly redundant, though currently harmless. It may stop being harmless in a future improvement to the way attributes are handled, so best not to do that any more.

  • This set of changes does not require a perldelta entry.

We need to use a dedicated grammar type; or at the very least, not use
`subattrlist` for doing this. The previous use of `subattrlist` had the
side-effect of passing every attribute list for a class via the
`apply_builtin_cv_attributes()` function. That was pointlessly
redundant, though currently harmless. It may stop being harmless in a
future improvement to the way attributes are handled, so best not to do
that any more.

The new structure repurposes the previous `myattrlist` to be a
non-optional attribute list, and defines `optattrlist` to use for both
class and field attributes.
@leonerd leonerd changed the title Define and use a classattrlist in perly.y Don't treat class attributes as sub attributes in perly.y Nov 14, 2025
@happy-barney
Copy link

Just one low priority comment (mostly coming from my ongoing adaptation of grammar for GLR parser):

It will be nice to have dedicated non-terminals for each usage of attributes, for example:

class_attributes
    :   optattrlist
    ;
field_attributes
    :   optattrlist
    ;

Reasoning:
in future they can be upgraded to something like this (meaning, not implementation):

class_attributes
    :   { push_attribute_context (CLASS); }
        optional_attributes
        { pop_attribute_context (); $$ = $optional_attributes; }
    ;

@leonerd
Copy link
Contributor Author

leonerd commented Nov 15, 2025

It will be nice to have dedicated non-terminals for each usage of attributes, for example:

I think if that sort of thing were to be added, it would be easy enough to split the grammar rules at that point. I'd prefer currently to keep the rules agnostic about what their target is, as it keeps them simpler. There's no need to have different kinds just at the moment.

@happy-barney
Copy link

Comment was low priority, just to make it little bit nicer. I guess you are right, related change once it will introduced may be even better to be part of that changeset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants