Skip to content
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

Implement RST visitor #211

Open
fabianschuiki opened this issue Oct 31, 2020 · 0 comments
Open

Implement RST visitor #211

fabianschuiki opened this issue Oct 31, 2020 · 0 comments
Labels
C-enhancement Category: Adding or improving on features. L-vlog Language: Verilog and SystemVerilog.

Comments

@fabianschuiki
Copy link
Owner

At the moment we have the AST and a corresponding visitor on that AST. The ResolutionVisitor, which ensures all names have been resolved and, more importantly, diagnostics related to names have been emitted early, uses this ast::Visitor. The AST however contains ambiguities, which now shows up for example in SubroutinePort. Resolving names is possible for one variant of the ambiguity (anonymous port with a named type), but not possible for the other (named port with implicit type). The ResolutionVisitor should rather be a rst::Visitor, which goes over the AST with resolved ambiguities.

It's not yet quite clear how to do this. Intuitively one would want to "inherit" from the ast::Visitor and "override" a few of the callbacks (the ones which may walk over ambiguities) in order to resolve them up front before calling corresonding functions for the resolved node. Not sure how to do this in Rust without just re-implementing the whole trait, though.

@fabianschuiki fabianschuiki added L-vlog Language: Verilog and SystemVerilog. C-enhancement Category: Adding or improving on features. labels Oct 31, 2020
fabianschuiki added a commit that referenced this issue Oct 31, 2020
Add a resolution query for the type/name ambiguity in subroutine ports.
This currently needs to be called manually for visitors, which is a bit
annoying. This should be improved in #211 later.

Contributes towards function calls in #168.
fabianschuiki added a commit that referenced this issue Oct 31, 2020
Add a resolution query for the type/name ambiguity in subroutine ports.
This currently needs to be called manually for visitors, which is a bit
annoying. This should be improved in #211 later.

Contributes towards function calls in #168.
fabianschuiki added a commit that referenced this issue Nov 3, 2020
Add a resolution query for the type/name ambiguity in subroutine ports.
This currently needs to be called manually for visitors, which is a bit
annoying. This should be improved in #211 later.

Contributes towards function calls in #168.
fabianschuiki added a commit that referenced this issue Jan 8, 2021
Add a resolution query for the type/name ambiguity in subroutine ports.
This currently needs to be called manually for visitors, which is a bit
annoying. This should be improved in #211 later.

Contributes towards function calls in #168.
fabianschuiki added a commit that referenced this issue Jan 9, 2021
Add a resolution query for the type/name ambiguity in subroutine ports.
This currently needs to be called manually for visitors, which is a bit
annoying. This should be improved in #211 later.

Contributes towards function calls in #168.
fabianschuiki added a commit that referenced this issue Jan 16, 2022
Add a resolution query for the type/name ambiguity in subroutine ports.
This currently needs to be called manually for visitors, which is a bit
annoying. This should be improved in #211 later.

Contributes towards function calls in #168.
fabianschuiki added a commit that referenced this issue Jan 16, 2022
Add a resolution query for the type/name ambiguity in subroutine ports.
This currently needs to be called manually for visitors, which is a bit
annoying. This should be improved in #211 later.

Contributes towards function calls in #168.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Adding or improving on features. L-vlog Language: Verilog and SystemVerilog.
Projects
None yet
Development

No branches or pull requests

1 participant