Determining range of alias to string in record

[avelure]

This might need to be checked in the LRM, but I was under the impression that there is no difference between using an alias and the original object. In the following code the range for 'others' can be determined for the direct assignment, but not for the assignment via an alias. GHDL also complains on the same issue.

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

entity test is
end entity test;
architecture beh of test is
  type t_vvc_config is
  record
    clock_name : string(1 to 30);
  end record;
  signal vvc_config : t_vvc_config;
  alias clock_name      : string is vvc_config.clock_name;
begin

  process
  begin
    vvc_config.clock_name <= (others => NUL);
    clock_name <= (others => NUL);
    wait;
  end process;

end architecture beh;

$ nvc --std=08 -a test_string_range.vhd -e test-beh -r
** Error: index range of array aggregate with others choice cannot be determined from the context
    > test_string_range.vhd:19
    |
 19 |     clock_name <= (others => NUL);
    |                    ^^^^^^^^^^^^^

[nickg]

@bpadalino also reported the same issue when he was trying to get UVVM to work (I guess that's where this is from too). I think this error is reported correctly, but I may be wrong. I'd need to check the LRM carefully.

An others association can only be used where the aggregate has a constrained array subtype. Here the subtype is determined by the LHS of the assignment. clock_name is declared with type string which is an unconstrained type, and that then gets propagated to the type of the aggregate. A simple fix is to remove the type from the alias declaration (or provide a fully constrained type):

alias clock_name is vvc_config.clock_name;

[avelure]

Yes, it's from the UVVM clock_generator_vvc. I kind of understand why then, but I assumed since an alias always is reflecting an object and as that object in this case is constrained, then that those constraint would be applied to the string.

[nickg]

This has been reported by at least three people now so I've decided to be pragmatic and implement the GHDL behaviour when --relaxed is passed. The UVVM sources now compile with modification.