Can't find type of argument

[nblei]

I am trying to add support for unions to veryl:

The relevant addition to the grammar is below

UnionDeclaration: Union Identifier LBrace UnionList RBrace;

UnionList: UnionGroup { Comma UnionGroup } [ Comma ];

UnionGroup: { Attribute } ( LBrace UnionList RBrace | UnionItem );

UnionItem: Identifier Colon ScalarType;

Note that this is largely mimicking the existing grammar for structs:

StructDeclaration: Struct Identifier LBrace StructList RBrace;

StructList: StructGroup { Comma StructGroup } [ Comma ];

StructGroup: { Attribute } ( LBrace StructList RBrace | StructItem );

StructItem: Identifier Colon ScalarType;

If I replace UnionItem in the definition of UnionGroup with StructItem and remove the definition of UnionItem, parol generates a parser successfully, otherwise it errors with

  error: Parol error
   = Can't find type of argument UnionItem
   = No details

I would like to have UnionItem as a separate non-terminal, as the auto-generated data structures do not include parent references, thus distinguishing between a StructItem in a StructDeclaration and a StructItem in a UnionDeclaration would involve something let setting global state, which I would like to avoid.

Full grammar: https://github.com/nblei/veryl/blob/add_token/crates/parser/veryl.par

[jsinger67]

The error message is misleading and I will have a look at this.
But generally StructItem and UnionItem are structural identical and therefore also StructList and UnionList will be.
Try to factor them out in a more generally MemberList resp. MemberItem. So both can use the same and ambiguity should be resolved.

[jsinger67]

@nblei ,
I can reproduce the problem you described with your changes.
I'm pretty sure, the symbol table resolves the type of the UnionItem erroneously to the already inserted StructItem because of structural identity.
Currently I’m not sure if this is really a bug and how parol should handle structural identity in general.
Let me explain why.
If you introduce two non-terminals with the same RHS of their productions like

StructItem: Identifier Colon ScalarType;
UnionItem: Identifier Colon ScalarType;

you have at least made your grammar unnecessary complex. The types parol would normally derive from your grammar have been doubled and the compile time for parol’s grammar analysis has increased.

On the other hand, from a user’s perspective the types may be structural identical, but they can be different in terms of their implementation.

I will think about this, but currently I tend to think this is a bug in parol.

[jsinger67]

This confirms my guess. The symbol table used the already existing type StructItem.

[nblei]

Yeah, I get that, hence why I didn't report this as a bug :-).

In my use case, which is using parol as a parser for a hardware description language, I am all in favor of increased capabilities at increased computational cost, since lexing/parsing the language is computationally insignificant in relation to logic synthesis, APR, etc.

[jsinger67]

@nblei
I found that the loss of the type-information is happening in a very early stage of grammar processing.
To be precise, during the left factoring phase.
Since this is a very fundamental step in grammar processing that has huge influence on the number of lookahead tokens the parser needs to consider, I think I must rethink my assessment of about how to classify this issue.
I was willing to accept that this is a bug, which I refrain to do for now.
Thus, I ask for some deferral.

[jsinger67]

Fixed with commit b9020fd
This commit is based on 8e78a8b (Removed optimization in grammar transformation => eliminate_duplicates)

A version 0.23.1 will soon be released 😊
Have fun! 🎉