[Bug]: zippered iteration error when storing forall expression with filter into a typed array

[mppf]

Summary of Problem

Description:
I'm investigating filtering predicates with a forall expression because I'm looking at an algorithm that would benefit from it. I'm talking about syntax like the spec describes. See also #26384 which notes that they don't appear to result in a parallel loop.

If the LHS of such a forall expression is an array with a type, I see a "zippered iterations have non-equal lengths" error. It runs without issue if I declare the LHS variable without a type.

Is this issue currently blocking your progress?
no

Steps to Reproduce

Source Code:

use Random;

config const n = 20;
config const debug = false;

proc main() {
  var A:[0..<n] int;
  fillRandom(A, min=0, max=9, seed=1);
  if debug then writeln(A);

  // count the zeros
  writeln("counting");
  var numZeros = 0;
  forall x in A with (+ reduce numZeros) {
    if x == 0 then numZeros += 1;
  }

  // store the positions of the zeros, not parallel
  writeln("manual way");
  var ZerosS0:[0..<numZeros] int;
  var counter = 0;
  for (x,i) in zip(A,A.domain) {
    if x == 0 {
      ZerosS0[counter] = i;
      counter += 1;
    }
  }
  if debug then writeln(ZerosS0);

  writeln("forall loop with filter stored in typed");
  var ZerosP2:[0..<numZeros] int = [i in A.domain] if A[i] == 0 then i;
  if debug then writeln(ZerosP2);
  assert(ZerosP2.equals(ZerosS0));
}

Compile command:
chpl bb.chpl

Execution command:
./bb

$ ./bb
counting
manual way
forall loop with filter stored in typed
$CHPL_HOME/modules/internal/ChapelArray.chpl:2533: error: zippered iterations have non-equal lengths

Associated Future Test(s):
TODO

Configuration Information

Chapel 2.3 pre-release on an Ubuntu PC.

[bradcray]

Interesting case! I'm finding that if the last element of A is forced to zero before counting and executing the loop, the error goes away. That makes me imagine that the current check for "Did one zippered iterator run out before the other?" only takes into account that iterations remain, not that in the presence of a filter, all subsequent elements might be false such that effectively we're done.

This example is also making me realize that it's probably not only the "capture in a new variable" aspect of the previous issue that thwarts parallelization, but the filtering in general (since, in our normal parallelization, it'd be difficult to anticipate where a given filtered element should align to). I'll update my previous comment.