Add with keyword to chpl-mode.el
Ensure catfiles (compiler output, etc) is added to final output when using slurm prediff.
Merge pull request #357 from thomasvandoren/update-slurm-prediffer

Ensure catfiles (compiler output, etc) is added to final output when using slurm prediff.

This fixes an error where the output file generated by the compiler was not included in the final output,
and resulted in mysterious failures. I think the bigger issue is that catfiles are evaluated before the
system prediff. I am not yet sure if there is a reason for that, but this change is useful regardless.
Fix Typo in README.chplenv
Merge pull request #359 from ronawho/fix-chplenv-typo

Fix Typo in README.chplenv
Skip regex-dna testing if a launcher is present
Merge pull request #360 from benharsh/regex-comm-fix

Skip regex-dna testing if a launcher is present
Use output file specified by user instead of appending %j.out.

Update slurm-srun and slurm-gasnetrun_ibv launchers to treat
CHPL_LAUNCHER_SLURM_OUTPUT_FILENAME env var as full file path. They both use
the value directly as the --output argument when calling sbatch.

Previously, these launchers would append "%j.out" to the user specified value
and use that for --output argument. This is unnecessary (and slightly
restrictive) because the user can specify a value with escaped characters, like
%j, that slurm will populate with the appropriate values.

Confirmed with @ronawho that this is an ok change.
Merge pull request #361 from thomasvandoren/update-slurm-launcher-env

Use output file specified by user instead of appending %j.out.

Update slurm-srun and slurm-gasnetrun_ibv launchers to treat
CHPL_LAUNCHER_SLURM_OUTPUT_FILENAME env var as full file path. They both use
the value directly as the --output argument when calling sbatch.

Previously, these launchers would append "%j.out" to the user specified value
and use that for --output argument. This is unnecessary (and slightly
restrictive) because the user can specify a value with escaped characters, like
%j, that slurm will populate with the appropriate values.

Confirmed with @ronawho that this is an ok change.
Merge pull request #353 from thomasvandoren/update-chpl-mode-el

Add 'with' keyword to chpl-mode.el
Replace some uses of var that were missed in the var->ref switch
Change line numbers for test_var_iterator5_error

This test expects a compiler failure, but it has the explicit line numbers in
the .good file. The line numbers changed with the addition of arrays as vectors work
Merge pull request #364 from ronawho/fix-line-number-warnings

Change line numbers for test_var_iterator5_error

[will have @diten review post-commit]
Merge pull request #363 from ronawho/var-to-ref-fixes

Replace some uses of var that were missed in the var->ref switch

[reviewed by @Kyle-B]
Add overflow checks to bounded iterators

The default iterators do not support positively strided ranges whose last index
is max(indexType) or negatively strided ranges whose last index is
min(indexType). E.G "for i in max(int)-10 .. max(int)"

The above example turns into the following generated code

for (i=max(int)-10; i < max(int); i+=1)

and everything is less than max(int) so you would have an infinite loop.

Prior to c for loops our iterators didn't work for maximal ranges, but they did
work for the above example. They generated the equivalent of:
for (i=max(int)-10; i != max(int)+1; i+=1)

This relies on well defined integer overflow, which is not valid since integer
overflow has undefined behavior in c.

So while the new iterators aren't as capable as the old ones, they're more
performant, and don't cause undefined behavior.

To deal with this limitation I added a function that checks for overflow and
halts with a warning about them.

If a user really wants to iterate over such a range, I added a generalIterator
that works for any range including maximal ranges, but is terribly slow. To
avoid the performance cost the user can either rewrite their loop to avoid the
problem or try a wider type if they aren't already at the max size.

If they don't care about performance they can toggle
useOptimizedRangeIterators=false which is a big hammer that will use the slow
general iterator for all cases. This will lead to absolutely awful performance.
I can't think of a way to support such ranges in an optimal  fashion, but there
may be a better way to let users pick and chose what loops use the general
iterator.

The general iterator exposed some bugs in the c for loop implementation. Namely
that the break and continue labels were getting added to the wrong structure.

There are also some tests changes.

trivial/deitz/test_max_range_iteration
types/range/hilde/maximalRange

were tests that has ranges that the new iterators do not support. I updated
these tests to include the new error. I also added compopts so they tests the
unoptimized iterator. With bounds checks off and the optimized iterators being
used these tests would have infinite loops. We break to avoid this, so one
variation of the test captures the fact that these infinite loops will occur
(and are expected, although unfortunate.)

I also added a test that checks similar behavior as the previous two tests but
it does it for unsigned and signed variations for positively and negatively
strided ranges.
Need to cast stride.

The stride needs to be casted when the idxType is unsigned. This is still
correct even if the stride is negative because val:uint + -val2:uint is the
same as val:uint + max(uint)-abs(val2)+1

E.G. 1:uint + (-1):uint ends up being 1 + 255 which will end up being 0 since
unsigned integer overflow is well defined
Change bigStride to prevent overflowing

[ok'd by brad]

Quote from brad:

"Re-reading the history of this test, it was basically guarding against
some assumptions in the early range code that the idxType and/or stride
were 32-bits.  I think as long as the stride for this thing can't be
stored in an int(32), my earlier self would be happy.  For example,
maybe something like:

  1..2*(n/3) by n/3

(with some +/-1's in there to get a few values without hitting the
overflow issue?).  I can take this if you want."
Change atomictest to prevent range iterator overflow

[ok'd by brad]

quote from brad:

"Elliot says he doesn't think this is a particularly compelling example,
which I'd agree with.  We can just set n to be something smaller. "
Change fannkuch-redux-blc.chpl to use an unbounded range

This is identical to what brad did to the other fannkuch versions in
0b09c9534e5ef7bfabdd6040f76b1e4ea817a320

Just changing this test as well
Cast histoSerial iterator indices so they don't overflow the iterator

The iterator attempts to do something like "for 0:uint..length:uint by -1" and
so the last iteration will result in overflow since 0 -1 for uints will
overflow. This just casts the uint32 to int64s to prevent that