FWD » Core Development » Base Language

While testing the task #9841 I discovered this case where FWD matches on the wrong constructor.

CLASS task.ClsA:
    CONSTRUCTOR PUBLIC ClsA (INPUT a AS DECIMAL):
        MESSAGE "Matched DECIMAL constructor.".
    END CONSTRUCTOR.
    CONSTRUCTOR PUBLIC ClsA (INPUT a AS INTEGER):
        MESSAGE "Matched INTEGER constructor.".
    END CONSTRUCTOR.
END CLASS.

In progress, the following code resolves to the constructor taking integer but FWD sometimes matches on the one taking decimal.

DEFINE VARIABLE a AS CLASS task.ClsA.
a = NEW task.ClsA (1).

We tried wrapping every literal given as argument to a NEW function call but that resulted in a regression. See #9841-42.

I traced the problem to the ControlFlowOps.resolveLegacyEntry() method which after the initial refinement phase when it checks for an exact match, it "normalizes" the native java int argument to the type expected by the first InternalEntry instance in the list.

In other words, the problem is that if there are 2 methods one expecting integer and the other decimal, FWD would match the first one that comes across which might not be the one expected because native java int type can be transformed to both integer and decimal. I suspect that the same problem can occur for native java string and progress character and longchar datatypes.

Besides this, Greg mentioned:

We probably should leave behind a matchType annotation at the call site that records "fuzzy" or "exact".