forall-over-forall results in empty array

[vasslitvinov]

In the test:

test/arrays/shapes/skyline.chpl

each element of the resulting array is empty. Even though it (each element) IS assigned a variable-length array. Cf.

test/arrays/ferguson/from-iterator/skyline.chpl

works properly because the elements of the resulting array are initialized, not assigned, from the inner arrays created by makeArray.

Cf. in this code:

  var B1 = [i in {1..n}] makeArray(i);

we get size-mismatch error. Why no such error in our skyline.chpl ?

Because for the statement:

  var B2 = nested forall expression...;

we call:

  B2 = initCopy(ir_outer);

which invokes:

  proc initCopy(ir_outer) {
    var result ....; // array of arrays
    forall (r, src) in zip(result, ir_outer) do
      r = src;
    return result;
  }

where r is an inner array; src is an inner _iteratorRecord.

The assignment "r = src" invokes proc =(ref a: [], b), which invokes

  proc chpl__transferArray(a, b) {
    forall (aa,bb) in zip(a,b) do
      aa = bb;
  }

There, 'a' is the inner array and 'b' is the inner _iteratorRecord.

Because of how we create result's element type, all result's elements - inner arrays - start out with an empty domain. The 'forall' runs the DRdom leader on such an inner array. It either does not yield anything, or yields an empty set of indices. The corresponding follower of the inner _iteratorRecord is either not invoked, or is simply not equipped to detect the size mismatch.

Therefore no size-mismatch error is reported. Also because of this, the inner _iteratorRecord's elements are never transferred the inner array, so the elements of 'result' remain empty.

Cf. with B1 above, 'src' and 'b' are an inner array. So "r = src" invokes the array-to-array assignment. That DOES check size mismatch and does result in the mismatch error at run time.

This is closely related to #11039.

[bradcray]

@vasslitvinov: From your investigations so far, does this issue seem to be related to issue #10374? [edited to update issue number]

[bradcray]

Oops, I missed #10374. Substitute that for my question above.

[vasslitvinov]

@bradcray - yes, it is related to #10374.

However, before we even consider coming back to this issue, we need to resolve #11039, which is the design question "what do we WANT to happen in this case?"

Meanwhile the behavior of this test is changed in #11501, formerly #11319, to be a compile-time error "cannot build arrays of arrays using forall expressions".