Fix use reference parsing of instantiated packages #1056
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Another day, another attempt to submit something useful :)
What is the status quo:
The VUnit VHDL parser understands the following line:
use firstname.secondname;
as a reference to a library "firstname". This is an issue if firstname is instead the name of an instantiated package. Later on VUnit obviously cannot find such a library and produces a warning.
What this patch changes:
The changes in this PR filter out all the detected references in a design file based on the detected package instantiations. Only those references, that target a library, whose name is identical to that of an instantiated package, are removed.
Side effects
I believe this to be without undesirable side effects. If, at any point, a library and an instantiated name exist, that have the same name, then the code is malformed and should fail during compilation. It is therefore always safe to remove references to assumed libraries if there exists a package with the same name.
Scope
This does not fix all issues with instantiated packages though. The filter does not know about the declaration of instantiated packages in other design files. Those could be the relevant primary units (package, entity) or simply inside another visible package. Detecting those cases would require a more complete semantic analysis of the code though.