More range whitespace rules

[maltaisn]

There doesn't seem to be any rules to specify the number of spaces in these cases related to ranges:

library ieee;
  use ieee.std_logic_1164.all;

entity b is
  port (
    c : in    std_logic_vector(   7 downto      0)   -- 1, 2
  );
end entity b;

architecture a of b is

  type my_array is array        (natural     range     <>)   of      integer;    -- 3, 4, 5

  type my_array2 is array        (natural     range     0      to   7)   of      std_logic_vector(   7   downto     0);    -- 1, 2, 3, 4, 5

begin

end architecture a;

1. In range specification, between starting parenthesis and first bound
2. In range specification, between range type keyword (to/downto) and second bound
3. In range definition, between index type and range keyword
4. In range definition, between range keyword and its definition
5. In array definition, between array keyword and range definition.

[JHertz5]

Hi @maltaisn
Thanks for raising this issue. I've taken a look and I can recreate your issue. I'll have a working on some changes for you. There is a lot here, so I'm going to split these into multiple issues to make the work easier to manage. For each of the items in your numbered list:

1. This would ideally be covered by whitespace_005, but this rule ignores spaces before numbers. I think that we can solve this by making that behaviour configurable. Then we can disable that option to remove whitespace after opening parentheses. On the other rules, I think new rules are needed.

2. There are a few constructs that use ranges and not all of them are parsed very well by the current codebase - in this example, the slice expression is simply parsed as todo.

22 |   x <= y(7 downto 0);
<class 'vsg.token.concurrent_simple_signal_assignment.target'>
<class 'vsg.token.concurrent_simple_signal_assignment.assignment'>
<class 'vsg.token.todo.name'>
<class 'vsg.token.todo.open_parenthesis'>
<class 'vsg.parser.todo'>
<class 'vsg.token.direction.downto'>
<class 'vsg.parser.todo'>
<class 'vsg.token.todo.close_parenthesis'>
<class 'vsg.token.concurrent_simple_signal_assignment.semicolon'>

Given this, I think the most sensible approach here is to create whitespace rules around the direction keywords (to & downto), in the same style as the rules that check for spaces around operators, e.g. (whitespace_011). Here I suggest new rules, whitespace_102 and whitespace_103 to check for spaces before and after direction keywords. Similar to whitespace_005, I think an option for ignoring whitespace before numbers might be desriable for whitespace_103, but I might wait until this is requested rather than implementing it preemptively as it adds quite a bit to the work.

3. There are two types of range keyword - index_subtype_definition.range_keyword and range_constraint.range_keyword. I suggest that the best approach here would be two new rules, index_subtype_definition_100 and range_constraint_100 to handle whitespace before the range keyword.

4. Same as 3, but with whitespace after the range keyword. Rules index_subtype_definition_101 and range_constraint_101.

5. Similar to 3 and 4, there are two keywords in the codebase's parsing - unbounded_array_definition.array_keyword and constrained_array_definition.array_keyword. Each of these would have its own rule for whitespace after the array keyword. unbounded_array_definition_100 and constrained_array_definition_100. It wasn't mentioned in your request, but I'll also add rules to remove excess whitespace around the of keywords in these array definitions.

Your rule suggestions are handled by the issues in the task below

Your Number	Subtask Issue	Status
1	#1489	#1498 raised
2	#1490	#1493 raised
3	#1491	#1491 raised
4	#1491	#1491 raised
5	#1492	#1495 raised

[JHertz5]

@maltaisn I've raised PRs to address (hopefully) all of your requests in this issue. When you have a chance, please try these branches out, check that they resolve your problems and let me know. If you run in to any issues or have any questions, please let me know. Thanks!

[JHertz5]

@maltaisn Just pinging you again - would you be able to check the branches to see whether they work for you? The branches are ready to be merged and are just waiting for you feedback.