Note: this is an opinion post.
While this does appear to be a tool bug (have you tried in Vivado 2020.1), for myself I have come to the conclusion that sometimes, using uncosntrained ports without generics can be more of an annoyance than a help. For example, unconstrained outputs must always be connected to something to allow sizing, even if you really want them unconnected, so you end up needing a dummy signal to allow it to compile. A generic can avoid this.
Additionally, if you do something like this:
entity dff is
port map (
clk : in std_logic;
d : in std_logic_vector;
q : out std_logic_vector
)
end entity;
architecture a of dff is
begin
process(clk)
begin
if rising_edge(clk)
q <= d;
end if;
end process;
end architecture;
Then a size missmatch between Q and D is not picked up until runtime because it does not see the size missmatch until it actually tries to assign D to Q. If a generic was included, then the error would be picked up at elaboratio when it maps the ports.
You also, cannot do something like this because of static rules:
d_inst : entity work.dff
port map (
d => to_slv(some_record_signal)
...
Here, if there was a generic, the conversion is allowed because the size of D is already known. The work around for the above is to have a correctly sized SLV signal already. But with a generic, you can simply do this:
d_inst : entity work.generic_dff
generic map (
W => to_slv(some_record_signal)'length
port map (
d => to_slv(some_record_signal)
...
and no extra dummy signal is needed.
