Refactor underscore ban

[mandolaerik]

• Refactor underscore ban
• Remove old underscore ban
• Ensure discard refs work with new API

[lwaern-intel]

Prefer ident_or_discard_ref.

[mandolaerik]

Agree

[lwaern-intel]

I want to investigate a bit more as to why I ran into reduce/reduce conflicts...

[lwaern-intel]

I prefer the token be named DISCARDREF.

[mandolaerik]

Disagree weakly. Other keyword-formed tokens are named as the keyword.

[lwaern-intel]

It should be 1.4 exclusive, no? Way I went about it in my WIP work was, in dmllex14:

keywords_dml14['_'] = 'DISCARDREF'
tokens.add('DISCARDREF')

[mandolaerik]

Sure, although somewhat 'tomato tomato'.

[lwaern-intel]

@mandolaerik expression_member was the issue! We want to support _ as the name of a member of a layout or struct. We cant with this approach unless we split cdecl to cdecl and cdecl_for_variable(???) and tweak expression_member. In my WIP I failed to consider the cdecl issue, but did recognize the expression_member issue; when I tinkered with this (ident_decl/ident rather than ident/ident_or_underscore, and ident_decl just leverages the ident), I encountered a reduce/reduce conflict with statement_delay_hook_one_msg_param, as at:

after whatever -> [ident] $: m();

what was previously a shift/reduce conflict that could be resolved via %prec bind now becomes a reduce/reduce conflict, as [ident] can be reduced either to objident or ident_decl.

Your approach where both ident and ident_or_underscore have identical defs except ident_or_underscore also accepts _ blows up even harder, but I think has the same root issue of statement_delay_hook_one_msg_param and expression_member causing a reduce/reduce conflict instead of simply a shift/reduce one.