The test:
    memory/sungeun/refCount/domainMaps.chpl

reports leaking additional 16 bytes in this assignment:

    A = -1;

where 'A' is an array distributed with any of the domain maps tested
except the default when localemodel=flat.

The culprit is heap allocation of chpl__leadIter.
While it is questionable whether chpl__leadIter should be heap-allocated,
the leak will (hopefully) go away when we have a general fix for leaking
heap-allocated variables.

Therefore I am adjusting the .good to accept this leak increase.

Details follow for BlockDist - I omit unrelated pieces of the AST ...

* Consider the function that implements A = -1:

    proc =(a: [], b: int) {
      forall e in A do
        e = b;
    }

* Its body is represented by the parser:

    def chpl__leadIter;
    for <leader loop> {
      ... b is referenced in the follower loop ...
    }

* It is then rewritten for forall intents:

    def chpl__leadIter;
    for <array leader> {
      b' = ... derived from chpl__leadIter ...
      ... b' is referenced in the follower loop ...
    }

* BlockArr leader is inlined. It invokes BlockDom leader,
  which contains a coforall+on:

    iter <array leader> {
      coforall ... on ... {
        yield ...
      }
    }

  which is represented as a task function on_fn():

    proc on_fn() {
      yield ...
    }
    iter <array leader> {
      for ... call on_fn() ...
    }

* So when both leader iterators are inlined in expandIteratorInline()
  during lowerIterators(), we get:

    proc =(a: [], b: int) {
      def chpl__leadIter;
      proc on_fn() {
        b' = ... derived from chpl__leadIter ...
        ... b' is referenced in the follower loop ...
      }
      for ... call on_fn() ...
    }

* Note that expandIteratorInline() clones the original on_fn()
  into a nested function, whose def is placed where the loop body
  used to be. This is because the loop body is inlined into
  the on_fn() in place of its yield and so may reference
  local variables outside its scope.

* Then on_fn() is flattened. chpl__leadIter gets passed by reference:

    proc on_fn(...) { ... }
    proc =(a: [], b: int) {
      def chpl__leadIter;
      for ... call on_fn(&chpl__leadIter) ...
    }

  chpl__leadIter is of the type _ic_ i.e. _iteratorClass.
  It is a pointer and probably should be passed by value, and it isn't.

* During makeHeapAllocations(), in findBlockRefActuals(),
  chpl__leadIter is discovered to be passed by reference
  to a non-blocking function, and so gets heap-allocated.
  It does not get freed in the scope measured by the test,
  I did not investigate why.

  Details: coforall/cobegin task functions have FLAG_NON_BLOCKING,
  which is preserved during the coforall+on optimization.
  Recall that build.cpp creates a single on_fn() task function when
  Chapel source code has "coforall... on ... { }"

  This confuses run-time non-blocking-ness with source-code non-blocking-ness
  which, further, could be different from non-blocking-ness for
  compiler-inserted variables such as chpl__leadIter.
  We may want to revisit this. Archaeology: the responsible check in
  findBlockRefActuals() was added in 03850b17 aka r20807.

Disclaimer: the above may be incorrect or incomplete in some details.
For example, b' is actually obtained from the 2nd element of chpl__leadIdx,
which is a tuple, not directly from chpl__leadIter. The latter is involed
because there are multiple iterator inlinings. At some point the former
gets preserved as part of the iterator state, accessible via a field
of the latter. Or some such.