Subtype resolution is not finding subtype when defined in another pkg file in another library

[Tcenova]

/python3.11/site-packages/pyVHDLModel/__init__.py", line 845, in _LinkItems subtype = package._namespace.FindSubtype(element._subtype) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/python3.11/site-packages/pyVHDLModel/Namespace.py", line 116, in FindSubtype raise KeyError(f"Subtype '{subtypeSymbol._name._identifier}' not found in '{self._name}'.") KeyError: "Subtype 'Subtype_Name' not found in 'pkg_file1'." Subtype_Name is used in pkg_file1 but is defined in pkg_file2. I am still working through on how it searches for the subtype and why _parentNamespace might be None. Any suggestions on if this is expected to work? Or if not any thoughts on how it could work/be implemented?

[Paebbels]

Can you provide the example VHDL code you're using to investigate it?

---

Please note:
Linking types and objects is experimental.

[Tcenova]

I understand that the linking of types and objects is experimental. So far the linking of types has been very useful, and it just seems that some edge cases have issues. Are you open to me reporting more issues if I encounter them?

---

I cannot share the specific code I am using, but I created a very basic example of what causes the issue. It looks like its just an issue if a subtype is part of a different package file. Placing one of the package files in a different library didn't impact this error. This may actually be an issue now due to #78 adding resolution of record types.

pkg_file1.vhd:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

use work.pkg_file2.all;

package pkg_file1 is

  type t_test_record is record
    test_element : Subtype_Name;
  end record;

end package pkg_file1;

package body pkg_file1 is

end package body pkg_file1;

pkg_file2.vhd

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

package pkg_file2 is

  subtype Subtype_Name is unsigned(3 downto 0);

end package pkg_file2;

package body pkg_file2 is

end package body pkg_file2;

dut.vhd

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

use work.pkg_file1.all;

entity dut is
  port (
    i_clk : in std_logic;
    i_rst : in std_logic;

    i_test : in t_test_record;

    o_test : out t_test_record
  );
end entity;

architecture rtl of dut is

begin

process (i_clk)
begin
  if rising_edge(i_clk) then
    o_test <= i_test;
  end if;
end process;

end architecture;

[Paebbels]

Are you open to me reporting more issues if I encounter them?

Yes please report them here. I'm currently trying to bring (py)GHDL and pyVHDLModel again into sync. There are 1 or 2 bugs and the current working branch doesn't pass all tests in pyGHDL + pyVHDLModel.

I'll try to answer your questions and try to support you, but I'm not sure how responsive I can be. I have now 2 weeks of vacation and some Python projects need attention. Some need more code (like this) - which is ok - others need hard debugging because GitHub changed their infrastructure and broke my pipelines (that's unplanned and nasty debugging work).

[Paebbels]

Subtype_Name is used in Package_Name2 but is defined in Package_Name2 which is also in a different library

Is there a typo? I think one of them should be Name1, right? Can you please update the original question, to match the posted code, as you modified some of the names. Just to better understand the code / error message.

For me it looks like the "importing" is not correct. If the name of language entity isn't found and not present in the namespace, it feels like use ... and or ...all; didn't do it's job completely. I would start with a breakpoint at the importing of all names into the namespace by use work.pkg_file2.all; and check if the namespace was filled correctly.

When this is checked, you can go on to see how the namespaces are looked up for the specific name. If it's not filled correctly, it needs to be investigated what "all" finds.

[Tcenova]

I updated the question to align all names. I found the root cause though, which was related to using _identifier instead of _normalizedIdentifier when adding to the namespace. PR #82 should fix this.

[Paebbels]

I like the PR. Please accept the minor update to it and I can merge it.