Analyze Subprogram Instantiation Declarations

[Schottkyc137]

• Check that referenced subprogram exists
• Check that referenced subprogram is an uninstantiated subprogram (and not a regular subprogram)
• Check mismatch function / procedure instantiation
• Check that a function call does not denote an uninstantiated subprogram
• Resolve overloaded uninstantiated subprograms
• Check generic map aspect
• Declare the instantiated subprogram in the current scope
• Set reference to the uninstantiated subprogram

[kraigher]

Adding generics to the signature is a very invasive change. Are you sure this is the right approach?

[Schottkyc137]

I wasn't sure what the best place to store the generics is. Putting it here felt like the right place though as the generics can be thought of as a part of the signature. I initially also tried putting it into the Overloaded enum (creating an UninstSubprogram and UninstSubprogramDecl variant) but that was really tedious and cumbersome compared to the current solution.

[kraigher]

Isnt an uninstantiated subprogram supposed to be handled very differently from other subprogams? Adding enum variants to the Overloaded enum then seems like a good way to ensure as all existing code that handles normal subprograms should not also run for uninstantiated subprograms without careful consideration.

[kraigher]

Anyway I am not sure what is the best approach, just want to share my gut feeling. In the end you just have to try the approaches and see which works. The generic subprograms are one of the more complicated features of vhdl, a lot of strange corner cases exists with overloading and adding generics into the mix makes it more complicated.

[Schottkyc137]

I have changed the implementation slightly. Now, only a SignatureKey has a boolean value uninstantiated to differentiate between uninstantiated entities. I cannot remove it there at the moment as this signature key needs to be unambiguous for overloaded entities. Do you think this approach is better?

[Schottkyc137]

Alright, I think this is ready for review. I have also added some ignored tests that show the scope of this PR. All in all, this PR should cover most use cases. The ignored tests are mostly some edge-cases (e.g., recursive uninstantiated subprogram calls, uninstantiated subprogram calls as resolution function, e.t.c.). That being said, the ignored tests are obviously far from complete.

[kraigher]

I made a first overview of the code. Looks good and well tested. I will do a deeper review tomorrow.

[kraigher]

I had another look and I think it is solid. The only concern I have is it is really correct to add the SignatureCategory directly to the SignatureKey. It seems it is only necessary to be able to store uninstantiated subprograms and normal subprograms in the OverloadedName. Many other uses of SignatureKey should probably not care about SignatureCategory but this is then not reflected in the type which offers up the possibility of this field being something other than Normal. Would it not be more isolated to add a SubprogramKey which was a wrapper arround SignatureKey:

struct SubprogramKey {
  cat: SignatureCategory,
  key: SignatureKey,
}

We would use SubprogramKey in only in the places where we actually need to avoid conflict between uninstantiated and instantiated subprograms.