Skip to content

Initial draft of a public API to navigate and manipulate VHDL syntax #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 40 commits into
base: master
Choose a base branch
from

Conversation

Schottkyc137
Copy link
Owner

No description provided.

Schottkyc137 and others added 27 commits January 3, 2025 14:54
This is opposed to the previous implementation where the leading trivia would
only return the immediate leading trivia stored in the token, which could
be confusing. To get the trivia between two tokens, the user would have to
manually extract leading and trailing trivias for the current and the
previous resp. next token.
Implement greedy name parsing
@skaupper
Copy link

Regarding your comment here:
As far as I understand, you want to find a better way of generating AstNodes which are basically the user API. If you represent every variant of NodeKind with the macros from the ast_syntax_gen crate the file would get rather extensive.

If you say, you want to generate them from some description you are also considering providing the description using some kind of text file (e.g. JSON, YAML, whatever), am I right?
Contrary to the grammar, each token would get a name associated with it but in the end it would still be a representation of the original grammar.

Sure, the AstNodes shouldn't be as much of a pain as some of the parsing routines, but most productions are pretty straight forward as well. If you want a description to generate the AstNodes couldn't a lot of the productions be generated from the very same description if you get them into some kind of regular structure? signal_declaration etc. are some pretty trivial examples.


That's how I could imagine a description using YAML. It's basically the same as your macro approach but in a separate file and probably more readable? Is that the direction you imagined, or am I way off? :)

# `SignalDeclaration` is a sequence of nodes and tokens 
# with an optional alternative and an optional sequence
SignalDeclaration:
  sequence:
    - keyword: Signal
    - node: IdentifierList
    - token: Colon
    - node: SubtypeIndication
    - optional: true
      alternative: 
        - keyword: Register
        - keyword: Bus
    - optional: true 
      sequence:
        - token: ColonEq
        - node: Expression
    - token: SemiColon

# `IdentifierList` is a repeated node of `Identifier`s, 
# separated by a `Comma` token
IdentifierList:
  repeat: "+"
  separate_by: 
    token: Comma
  sequence:
    - token: Identifier

# Provide the implementations for these nodes manually
SubtypeIndication:
  raw: true
Expression: 
  raw: true

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