Closed brownts closed 1 year ago
I have tried to reproduce your issue with the current parser on master, but there is no subtype_indication in there. Are you using the latest version (the recent changes are unrelated, so it has been several months since the output of this test would have changed).
Here is the new test I added:
declare
type Color_Type is (Red, 'W');
Color : Color_Type := 'W';
begin
case Color is
when Red => null;
when 'W' => null;
end case;
end;
--------------------------------------------------------------------------------
(compilation
(compilation_unit
(block_statement
(non_empty_declarative_part
(full_type_declaration
(identifier)
(enumeration_type_definition
(identifier)
(character_literal)))
(object_declaration
(identifier)
(identifier)
(expression
(term
(character_literal)))))
(handled_sequence_of_statements
(case_statement
(expression
(term
(identifier)))
(case_statement_alternative
(discrete_choice_list
(discrete_choice
(identifier)))
(null_statement))
(case_statement_alternative
(discrete_choice_list
(discrete_choice
(character_literal)))
(null_statement)))))))
The subtype_indication will not show up in the parse tree because it is hidden, however if this were to have been parsed as an expression, the identifier and character_literal would have been wrapped in an expression (e.g., "(expression (term (identifier)))"), which they are not.
This is even more evident if you add field names to your tests. When you do that, you will see the "subtype_mark" field shows up in the discrete_choice. I use the "subtype_mark" field name in my highlighting rules to identify and properly highlight types in the language. This doesn't work with the discrete_choice as it's incorrectly parsing non-types this way.
In the following, I have modified your expected results to add in the field names (and your test still passes) and you will see the "subtype_mark" field name appears (which comes from the subtype_indication).
(compilation
(compilation_unit
(block_statement
(non_empty_declarative_part
(full_type_declaration
(identifier)
(enumeration_type_definition
(identifier)
(character_literal)))
(object_declaration
name: (identifier)
subtype_mark: (identifier)
(expression
(term
name: (character_literal)))))
(handled_sequence_of_statements
(case_statement
(expression
(term
name: (identifier)))
(case_statement_alternative
(discrete_choice_list
(discrete_choice
subtype_mark: (identifier)))
(null_statement))
(case_statement_alternative
(discrete_choice_list
(discrete_choice
subtype_mark: (character_literal)))
(null_statement)))))))
Thanks for the work here, sorry I did not have time to look into that this week. I'll find the time to review next week
Hi @briot:
I'm seeing an issue with parses involving
discrete_choice
when the value is anidentifier
,selected_component
,character_literal
, etc. These are being incorrectly parsed as_subtype_indication
when they should be parsed as anexpression
. The following simple example should demonstrate the problem:The interesting part of the parse tree involves the discrete_choice of the case statement. Both the "Red"
identifier
and "W"character_literal
are being parsed as_subtype_indication
, whereas "Green" and "Blue" both show correctly as an expression. I believe both "Red" and "W" should be parsed as expressions too. Acharacter_literal
isn't even a valid subtype name.I think the probability that a discrete_choice will contain an
expression
is much higher than it containing a_subtype_indication
and likely should be given higher priority. This issue manifests in many places where adiscrete_choice
is used, not just this one example. Yet another example is anenumeration_representation_clause
where all the enumeration identifiers are parsed as_subtype_indication
.parse_tree.txt