---
Signed-off-by: Brad Chamberlain <[email protected]>

---
Signed-off-by: Brad Chamberlain <[email protected]>

I considered doing this in the original draft since the value is
always known and the different callsites need different things,
but shied away from it worrying about code size increases.
However, I'm getting problems with module initialization orders
for tests like:

arrays/ferguson/array-initialization-patterns/array-init-replicated.chpl

---
Signed-off-by: Brad Chamberlain <[email protected]>

---
Signed-off-by: Brad Chamberlain <[email protected]>

(not to say they wouldn't be interesting to test on a single as well
to make sure there's no error, but getting the .good files right
doesn't seem worth the effort given that they'll vary from case to
case.

---
Signed-off-by: Brad Chamberlain <[email protected]>

…alaccess-error-improvements

… locales

It seems these have never worked, and that the tests written to see
whether they did were getting away with things?

Also, add a test showing why my implementation so far is insufficient
to make locality checks for Stencils work.

---
Signed-off-by: Brad Chamberlain <[email protected]>

…ncilDist

This adds a new iterator similar to localSubdomains() yet which
returns all stored local indices, whether part of the locale's
subdomain or not, to permit fluff to be considered "in bounds" for
local accesses.

---
Signed-off-by: Brad Chamberlain <[email protected]>

…alaccess-error-improvements

---
Signed-off-by: Brad Chamberlain <[email protected]>

---
Signed-off-by: Brad Chamberlain <[email protected]>

---
Signed-off-by: Brad Chamberlain <[email protected]>

…ases

---
Signed-off-by: Brad Chamberlain <[email protected]>

Also, add new test of multidim localAccess bounds violation to lock that
case in.

---
Signed-off-by: Brad Chamberlain <[email protected]>

---
Signed-off-by: Brad Chamberlain <[email protected]>

The main piece of feedback I'm acting on here is to update the comment
in StencilDom.doiLocalStoredSubdomains(), which had fallen out of date
when I removed the 'locale' argument to the iterator in a
late-breaking commit.  Here, I've updated it to note that the current
call should be communication-free since we are always answering the
question for 'here'.  I've also updated the stencil localAccess.chpl
test to wrap the localAccess calls in a `local` block to lock in that
no communication is required to implement the calls.

Then I took that same principle to the localAccess-block*.chpl tests
to lock in that the block localAccess calls do not require
communication.

Note that I used an unusual formatting scheme here because I didn't
want to have to update the line numbers of the error messages... :(

---
Signed-off-by: Brad Chamberlain <[email protected]>

Engin pointed out, rightly, that in updating these tests to make the
localaccess calls legal, I aso pointed out that we had a pre-existing
bug specific to the case of oversubsctibed locales that we didn't have
any tests catching.  So here, I've added the illegal accesses back at
the end of the test to lock in the remote accesses.

The reason that these cases are different is that our dsiLocalAccess()
calls on Block and Cyclic use different (arguably incorrect) logic
when used in an oversubscribed manner.

---
Signed-off-by: Brad Chamberlain <[email protected]>

While reviewing the block and cyclic versions of this test, it wasn't
clear to me why this stencil version of the test didn't require changes
when the others did.  It turns out that the answer is that it wasn't
ever enabled for multi-locale runs...  Fixing that here, and updating
it similar to the block and stencil versions.

---
Signed-off-by: Brad Chamberlain <[email protected]>

This adds a --checks flag to all these tests I've been working on for
localAccess() errors to ensure that they don't fail in --fast testing.
This may be the first time in years I've thought of this before having
the nightly tests point out my mistake (?).

---
Signed-off-by: Brad Chamberlain <[email protected]>

…for comm=none

---
Signed-off-by: Brad Chamberlain <[email protected]>