Skip to content

Enhance token types used by parsing model #4914

@pekkaklarck

Description

@pekkaklarck

On the lowest level the parsing model consists of tokens having different types. For most parts types are fine, but we have identified few issues with them. We should go them through and do at least the following:

  1. When assigning variables, we sometimes use the type VARIABLE and sometimes ASSIGN. Issue Use assing, not variable, with FOR and TRY/EXCEPT model objects when referring to assigned variables #4708 proposed changing the type used with FOR and EXCEPT AS variables from VARIABLE to ASSIGN to be consistent with variables created from keyword return values. This change was already done during the RF 7.0 development, but it was reverted because it turned out we still used VARIABLE with variables created in the Variables section and with the new VAR syntax and i wasn't possible to change also these types in RF 7.0. We need to check all places where variables are created and see can we use a common type in all cases and what that type would be.

  2. We currently use the type ARGUMENT with too many different tokens. For example, we use it with IF and WHILE conditions and with variable values in the Variables section and with the VAR syntax. This means that if we wanted to support conditional variable assignment like VAR ${x} IF $cond y ELSE z both $cont and y would have the ARGUMENT type. This in turn would make it unnecessarily hard to find the condition and value tokens. It's not certain is this kind of conditional variable assignment a good idea in general, but we should nevertheless change the token types so that implementation is possible. We could, for example, introduce a new CONDITION type to be used with all conditions.

  3. RETURN should be changed to mean the RETURN statement, not [Return] setting.

  4. There are some deprecated and unused token types we can remove. This includes WITH_NAME, FORCE_TAGS, FATAL_ERROR, FATAL_INVALID_HEADER and RETURN_SETTING.

  5. We should in general go through the token types and see do they make sense. The idea is to do a proper cleanup once and then try to keep the types stable.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions