jeremiah-c-leary
Control capitalisation of Type Casts
Is your feature request related to a problem? Please describe. Much like how when I write types and expect them to be capitalised or not, I would expect their castings to be capitalised the same way.
Describe the solution you'd like
I would like type casts capitalisation to be controlled, similar to rule type_mark_500 where if I have said that all types should be lower case.
STD_ULOGIC_VECTOR(foo) should be a violation and changed to std_ulogic_vector(foo)
Hi @GCHQDeveloper211
Thanks for raising this. I can recreate your issue: Test code
architecture a of b is
subtype my_type is STD_LOGIC_VECTOR(my_range);
begin
x <= STD_LOGIC_VECTOR(x);
x <= MY_TYPE(x);
end architecture a;
Output with default config:
$ bin/vsg -f test.vhd
================================================================================
File: test.vhd
================================================================================
Phase 6 of 7... Reporting
Total Rules Checked: 878
Total Violations: 1
Error : 1
Warning : 0
----------------+------------+------------+--------------------------------------
Rule | severity | line(s) | Solution
----------------+------------+------------+--------------------------------------
type_mark_500 | Error | 4 | Change "STD_LOGIC_VECTOR" to "std_logic_vector"
----------------+------------+------------+--------------------------------------
NOTE: Refer to online documentation at https://vhdl-style-guide.readthedocs.io/en/latest/index.html for more information.
The trouble with this is that these type casts are very difficult to distinguish from function calls without parsing the entire codebase. For example, with the current parser, the following code:
architecture a of b is
begin
y1 <= my_custom_function(x);
y2 <= my_custom_type(x);
end architecture a;
produces
--------------------------------------------------------------------------------
0 |
--------------------------------------------------------------------------------
1 | architecture a of b is
<class 'vsg.token.architecture_body.architecture_keyword'>
<class 'vsg.token.architecture_body.identifier'>
<class 'vsg.token.architecture_body.of_keyword'>
<class 'vsg.token.architecture_body.entity_name'>
<class 'vsg.token.architecture_body.is_keyword'>
--------------------------------------------------------------------------------
2 | begin
<class 'vsg.token.architecture_body.begin_keyword'>
--------------------------------------------------------------------------------
3 |
<class 'vsg.parser.blank_line'>
--------------------------------------------------------------------------------
4 | y1 <= my_custom_function(x);
<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.todo.close_parenthesis'>
<class 'vsg.token.concurrent_simple_signal_assignment.semicolon'>
--------------------------------------------------------------------------------
5 | y2 <= my_custom_type(x);
<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.todo.close_parenthesis'>
<class 'vsg.token.concurrent_simple_signal_assignment.semicolon'>
--------------------------------------------------------------------------------
6 |
<class 'vsg.parser.blank_line'>
--------------------------------------------------------------------------------
7 | end architecture a;
<class 'vsg.token.architecture_body.end_keyword'>
<class 'vsg.token.architecture_body.end_architecture_keyword'>
<class 'vsg.token.architecture_body.architecture_simple_name'>
<class 'vsg.token.architecture_body.semicolon'>
Note that the parser output for lines 4 and 5 are identical.
As a result of this, the problem is very difficult to solve without reworking the whole tool to parse complete codebases rather than individual files, or doing some fudging like treating function call and type casts a s a single token type. Basically, I'm just letting you know that this likely won't be resolved in the near future unfortunately.
Afternoon @GCHQDeveloper211 and @JHertz5 ,
As @JHertz5 mentioned, setting the case of the type casting would be difficult at this moment. I am working on a new data structure that should hopefully make this easier.
So I will put this on the back burner until the new data structure is ready.
Thanks,
--Jeremy
