FWD » Core Development » Base Language

Here's the testcase:

def  shared var var1              as date no-undo. 
def  shared var var2        like var1 no-undo.

The var1 variable should be converted as SharedVariableManager.lookupVariableUnreferenced, not as SharedVariableManager.lookupVariable.

Regarding the rule I mentioned earlier, I would suggest adding a new condition like the following at a first glance:

!(this.parent.parent.type == prog.DEFINE_VARIABLE and this.parent.parent.descendant(1, prog.KW_SHARED) and this.parent.parent.descendant(1, prog.KW_LIKE))

We need to exclude the 'meta' usage when checking the 'refid' - so in variable_definitions_unrefd.rules, do not use a refid if the parent is a KW_LIKE.

The same can be said about def temp-table tt1 field f1 like var1. - this is a 'meta' reference of the variable. Can you think of other syntax where a var can be used as a 'meta' reference?

Paula Păstrăguș wrote:

Regarding the rule I mentioned earlier, I would suggest adding a new condition like the following at a first glance:
[...]

KW_LIKE is processed later on in the conversion pipe-line - so the refid annotation there is required, to resolve the reference from which the definition is read.

Alright, I tried my quick workaround and the conversion completed successfully... However, I see your point. So just to confirm, you're suggesting that the better solution would be to update variable_definitions_unrefd.rules so that it doesn't remove the ID from the unrefd set?

Paula Păstrăguș wrote:

So just to confirm, you're suggesting that the better solution would be to update variable_definitions_unrefd.rules so that it doesn't remove the ID from the unrefd set?

Yes, for KW_LIKE parent and anything else you can find. 'unreferenced' in 4GL I think means 'is not read/written', not that is not used as a 'like'.

Okay, I’ll also look for other test cases that involve those kind of variables.

Please can you add CA-24875 to the case_num?
thank you

I looked for other scenarios, but it seems that LIKE remains the only problematic case in this context.

Here's a patch:

=== modified file 'rules/annotations/variable_definitions_unrefd.rules'
--- old/rules/annotations/variable_definitions_unrefd.rules    2023-05-10 07:41:38 +0000
+++ new/rules/annotations/variable_definitions_unrefd.rules    2025-05-21 12:19:13 +0000
@@ -135,7 +135,7 @@

       <!-- any reference to a variable in the set means that it should be
            removed since it must be a "live" var -->
-      <rule>isNote("refid")
+      <rule>isNote("refid") and parent.type != prog.KW_LIKE
          <action>unrefd.remove(getNoteLong("refid"))</action>
       </rule>

I performed an incremental conversion of a customer application, and everything went smoothly. Of course, to properly validate the fix, a full conversion should eventually be done. However, until then, Constantin, does the fix meet your expectations?

Paula Păstrăguș wrote:

However, until then, Constantin, does the fix meet your expectations?

Yes, thank you.

Committed to 10027a/15933.

Constantin, please double-check the revision.

If everything looks good, Radu, we’d like to add this to the merging queue.

Paula Păstrăguș wrote:

Committed to 10027a/15933.

Constantin, please double-check the revision.

The branch is OK.

If everything looks good, Radu, we’d like to add this to the merging queue.

Radu: lets plan to merge this on Monday.

Do we need this in #8966 branch?

Constantin Asofiei wrote:

Do we need this in #8966 branch?

We'll see in #9945 if these changes should be ported to 9866a.