Error raised on ranges used as case statement alternatives

[JHertz5]

I've got some code on which VHDL-LS is raising errors. However, I believe the code to be valid, and the code compiles and runs correctly in Vivado simulator (I haven't tested anywhere else).

I'm using VHDL-LS version 0.83.0, and the VHDL-LS VS code extension version 0.7.0.

The Error

The error in question is raised when I use a subtype which is a range, or the range attribute of that subtype, as the choice for a case statement alternative. I can't publish my source code, but I've created a MRE which exhibits the problem:

entity test is
end entity;

architecture rtl of test is

  type    t_my_enum is (A1, A2, A3);
  subtype t_my_enum_range is t_my_enum range A1 to A2;
  signal  my_sig_sub : t_my_enum;

begin

  proc_label : process
  begin

    case my_sig_sub is

      when t_my_enum'range => -- error here
        null;

      when t_my_enum_range => -- error here
        null;

      when t_my_enum_range'range => -- error here
        null;

      when A1 to A2 =>
        null;

      when others =>
        null;

    end case;

  end process;

end architecture;

Here is the same code in my editor, to show the error highlights:

Here are the details of the errors raised:

[{
	"resource": "<path>/test.vhd",
	"owner": "_generated_diagnostic_collection_name_#0",
	"code": "mismatched_kinds",
	"severity": 8,
	"message": "Range cannot be used as an expression",
	"source": "vhdl ls",
	"startLineNumber": 17,
	"startColumn": 12,
	"endLineNumber": 17,
	"endColumn": 27
},{
	"resource": "<path>/test.vhd",
	"owner": "_generated_diagnostic_collection_name_#0",
	"code": "mismatched_kinds",
	"severity": 8,
	"message": "subtype 't_my_enum_range' cannot be used in an expression",
	"source": "vhdl ls",
	"startLineNumber": 20,
	"startColumn": 12,
	"endLineNumber": 20,
	"endColumn": 27
},{
	"resource": "<path>/test.vhd",
	"owner": "_generated_diagnostic_collection_name_#0",
	"code": "mismatched_kinds",
	"severity": 8,
	"message": "Range cannot be used as an expression",
	"source": "vhdl ls",
	"startLineNumber": 23,
	"startColumn": 12,
	"endLineNumber": 23,
	"endColumn": 33
}]

My Justification

As mentioned above, I believe these errors to be raised incorrectly. Here are some excerpts from the VHDL-2008 LRM which lead me to believe that the code is valid:

First we need to get from a case statement down to a choice:

[§ 10.9]
case_statement ::=
  [ case_label : ]
    case [ ? ] expression is
      case_statement_alternative
      { case_statement_alternative }
    end case [ ? ] [ case_label ] ;

[§ 10.9]
case_statement_alternative ::= 
  when choices =>
    sequence_of_statements

[§ 9.3.3.1]
choices ::= choice { | choice } 

Now the definition for a choice shows that a discrete range is a valid choice, and the definition for a discrete range shows that I can use either a subtype indication (as long as it is a discrete subtype) or a range.

[§ 9.3.3.1]
choice ::=
  simple_expression
  | discrete_range
  | element_simple_name
  | others

[§ 5.3.2.1]
discrete_range ::= discrete_subtype_indication | range

[§ 6.3]
subtype_indication ::=
  [ resolution_indication ] type_mark [ constraint ]

Finally, from section 5.2.1, my enum types and ranges are discrete types and ranges:

"Enumeration types and integer types are called discrete types"

With all of this in mind, I believe that my usage of an enum subtype, or the range attribute of that subtype are valid VHDL code and that the "mismatched_kind" errors reported here by VHDL-LS are incorrect. Unless anyone disagrees with that, I would be very grateful if the tool could be updated to handle this code correctly.

[JHertz5]

This appears to also be the case for case generate statements and selected expressions.

[JHertz5]

Thanks for addressing the issue so quickly @Schottkyc137! Is there any action needed from my end or anything that I can do to help?

[Schottkyc137]

Thanks for addressing the issue so quickly @Schottkyc137! Is there any action needed from my end or anything that I can do to help?

So far there is nothing more, I think. Thanks for the nice issue, I could reproduce the code pretty easily and I also appreciate the research effort that went into it.

[JHertz5]

Excellent 👍 No problem at all! I'm glad that the extra detail was useful.