Report error when assigning to const arrays/domains.
Fix for a pointer truncation bug that is surfaced on Mac OS-X
Merge pull request #436 from noakesmichael/trunc-bug

Fix for a pointer truncation bug that is surfaced on Mac OS-X

This one line change addresses a long standing problem with managing Maps that has been exposed as intermittent failures on Mac OS X.  There was an operation on a MapElem included an explicit cast from uintptr_t to unsigned int hence losing the upper 32 bits of the address.  In this new version we simply preserve the uintptr_t.

My small concern is that I am unsure "why" the original author defined the return type to be a unsigned int in the first place.

a) This code has been tested against a repeatable failure case on Mac.

b) This code ran Lulesh for 2500 iterations; it had been failing approximately every 100 iterations or so.

c) Elliot has run this version on a program he has that used to fail intermittently.

d) Passed paratest.

e) Compiled on Mac/clang and Linux/gnu

Reviewed by Elliot
Merge pull request #430 from vasslitvinov/const-checking-for-assignment-to-arrays-and-domains

Report error when assigning to const arrays/domains.

For now, this error is enabled only for user-level variables,
i.e. ones with FLAG_CONST and not FLAG_TEMP.
This probably could be tuned to catch more errors.

While there: a loop index variable of an array type
is never const. That's because we currently yield
arrays by reference even from non-'ref' iterators.
See e.g. svn:r21676 aka 8d3b2c4

Non-constness applies even when the array is a part
of a tuple yielded by the iterator. Which is done
by the iterators boundaries() and dsiBoundaries()
in the test release/examples/benchmarks/miniMD/miniMD.chpl

Reviewed by Tom