Missing diagnostics on MOVE FUNCTION...

[fm-117]

Describe the bug Some intrinsic functions are not allowed in a MOVE statement, our parser allows it but IBM compiler doesn't.

To Reproduce (Type)Cobol code that cause the bug : (if any)

       IDENTIFICATION DIVISION.
       PROGRAM-ID. Pgm1.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 data-name  PIC X(20).
       01 data-length PIC 9(3).
       PROCEDURE DIVISION.
      *OK
           MOVE FUNCTION UPPER-CASE('hello') TO DATA-NAME
           MOVE FUNCTION UPPER-CASE('hello') TO DATA-length
           MOVE LENGTH OF data-name TO data-length
           COMPUTE DATA-LENGTH = FUNCTION LENGTH('hello')
      *KO on IBM compiler
           MOVE FUNCTION LENGTH ('hello') TO data-length
           GOBACK
           .
       END PROGRAM Pgm1.

Expected behavior Our parser should create a diagnostic on MOVE FUNCTION LENGTH('hello') according to the IBM compiler behavior.

TODO:

• determine which intrinsic functions are allowed and why
• improve intrinsic function descriptions in our code to add a return type (?)

[fm-117]

This is related to the nature of functions. Cobol defines 4 types of intrinsic functions based on their return type:

• Alphanumeric
• National
• Numeric
• Integer

And there are restrictions on how/where each types of functions can be used:

• Alphanumeric and National cannot be used inside arithmetic expressions (i.e. COMPUTE var1 = FUNCTION LOWER-CASE('A') is invalid)
• Numeric and Integer can only be used inside arithmetic expression (this is the explanation for the incorrect MOVE FUNCTION LENGTH('hello') above).

[fm-117]

While most functions have a pre-determined return type, some (MIN and MAX) are overloaded and actual return type depends on argument types. Therefore, the separation between text functions and number functions can't be done during syntax check and has to be done during semantic check.

To help find whether a function is used inside or outside of an arithmetic expression, the visitor must be improved. Adding BeginExpression and EndExpression methods (based on what is done for CodeElement) would allow to track expression context.

The overload resolution mechanism would have to integrate into existing code, see inheritors of FunctionCall and BuildProfile methods.