FWD » Core Development » Base Language

We need to investigate the implications of this:

def temp-table tt1 field f1 as int.
def buffer b1 for tt1.

procedure proc0.
  def parameter buffer rb1 for tt1.
  def parameter buffer rb2 for tt1.
  message buffer rb1:handle buffer rb2:handle. // same handle
end.

run proc0(buffer b1, buffer b1).

In #10483, it was found that FWD (wrongly) managed to open the scope for the same buffer instance, when calling the 'execute' methods for the class and super-classes (as a buffer from a super-class had its scope open emitted by conversion both in super and sub-classes, as it was used).

In the test above, using the logging added by #10483, it was found that a buffer can be used as argument multiple times for the same call.

We need to find the implications of this.

For now, changing ScopedList to avoid re-registering the same element prevents breaking the openBuffers dictionary:

=== modified file 'src/com/goldencode/p2j/util/ScopedList.java'
--- old/src/com/goldencode/p2j/util/ScopedList.java     2025-08-28 14:34:28 +0000
+++ new/src/com/goldencode/p2j/util/ScopedList.java     2025-09-14 13:18:48 +0000
@@ -243,6 +243,11 @@
    public void addAt(int depth, E element)
    {
       NodeList scope = getScopeAtDepth(depth);
+      if (scope.valueToNodes.containsKey(element))
+      {
+         // already registered
+         return;
+      }
       Node<E> n = new Node<>(element);

       if (size == 0)

But this does not solve other possible problems when the caller's buffer is bound to two or more parameter buffers at the callee, and what involves processing the scope at the callee multiple times for the same bound buffer.

Stefanel: please investigate this.

Committed revision 16165 on task branch 10567a:
- Avoid openScope call for the same buffer in the current scope.

Committed revision 16166 on task branch 10567a:
- Logging ScopeList.addAt when adding the same element more than twice.

I am OK with the changes in 10567a. they are cleaner than my attempt in #10818 in fact :)

Feel free to skip ChUI regression tests and pair this branch testing with another task that requires ChUI regression testing in the future. I think he changes are too small to require independent ChUI testing.
Please merge 10567a to trunk now.