Added const-ness checking for loop index variables
Squash line numbers when comparing .bad and .comp.out.tmp files.

This patch is intended to cut down on some testing noise.

If tests report errors relative to module code and the module code has changed for other
reasons, line numbers in the .bad file will get out of sync.  This modification of
sub_test normalizes line numbers out of the comparison, under the assumption that
the exact line numbers in module code are not of particular interest.

This normalization affects only comparison with the .bad file (not the .good file).

Line numbers for errors arising in user (non-module) code are still matched verbatim.

To identify error messages, the sed script matches only lines containing
"CHPL_HOME/modules".  It then replaces the first string of digits between two colons with
"nnnn".
Add missing <eol> in diff-ignoring-module-line-numbers script.
Add some new error messages for ref vars

Fatal error when using ref vars as members of classes/records.
Fatal error when ref vars are declared, but not initalized.
Fatal error when assigning a non-const ref to a const ref formal.
Update bug summary
Update ref var tests

Add two new futures:
test/variables/kbrady/ref-in-tuple.future
test/variables/kbrady/ref-member.future

Retire three old futures:
test/variables/sungeun/refvar-compare-nil.future
test/variables/sungeun/refvar-no-init-with-def.future
test/variables/sungeun/refvar-no-init-with-use.future
Change method->function
Added FLAG_INDEX_OF_INTEREST in one other case.
While there, also moved a couple of newTemp() allocations
to where they are used.
Default values for ref args should not be allowed, so turn this into
an "error message" future.
Slight change in bug summary to be more specific.
Add a future for default values for const ref arguments to functions.
Merge pull request #343 from sungeunchoi/test

Update a few futures

- Update text of test/functions/lydia/syntax-error-unclear-message*.future [reviewed by @lydia-duncan]
- Change test/functions/tzakian/implicit_arg_pass_by_ref.future  into an error message future
- Add test/functions/sungeun/const_ref_arg_default_value.future for default values for const ref arguments
Merge pull request #307 from Kyle-B/ref-var-fixes

Ref var improvements

Add some new error messages for ref vars:

Fatal error when using ref vars as members of classes/records.
Fatal error when ref vars are declared, but not initalized.
Fatal error when assigning a non-const ref to a const ref formal.

Update some ref var tests

Add two new futures:
test/variables/kbrady/ref-in-tuple.future
test/variables/kbrady/ref-member.future

Retire three old futures:
test/variables/sungeun/refvar-compare-nil.future
test/variables/sungeun/refvar-no-init-with-def.future
test/variables/sungeun/refvar-no-init-with-use.future
Update chpl_mem to default to dlmalloc or none when target arch is knc.

worked with @benharsh on this fix
Merge pull request #347 from thomasvandoren/fix-tcmalloc-for-knc

Update chpl_mem to default to dlmalloc or none when target arch is knc.

This is motivated by the fact that tcmalloc does not configure or build well in a knc environment. For
one, it tries to compile an then run some c++ code, which doesn't work with a knc compiler. There is
an option to cross compile by passing `--host=<some host string>` to `./configure`, but Ben and I ran
into other issues when we tried that. We decided that for now, it is best to not use tcmalloc
when compiling knc.

I worked with @benharsh on this fix.
Merge pull request #337 from hildeth/squashLineNumbersInBadFileComparison

Squash line numbers in bad file comparison



This patch is intended to cut down on some testing noise.

If tests report errors relative to module code and the module code has changed for other
reasons, line numbers in the .bad file will get out of sync. This modification of
sub_test normalizes line numbers out of the comparison, under the assumption that
the exact line numbers in module code are not of particular interest.

This normalization affects only comparison with the .bad file (not the .good file).

Line numbers for errors arising in user (non-module) code are still matched verbatim.

To identify error messages, the sed script matches only lines containing
"CHPL_HOME/modules". It then replaces the first string of digits between two colons with
"nnnn".
[reviewed by lydia]
Followed up on reviewers' comments.
Moved preFold of tuple indexing into resolveTupleIndexing()
by Tom's request.
Merge pull request #324 from vasslitvinov/const-checking-for-loop-index-variables

Implemented const-ness checking for loop index variables.

Also changed how _indexOfInterest is detupled in certain cases.

There are various cases that needed to be handled,
the ones I considered are listed in

  test/statements/vass/index-variable-const-errors.chpl

The way I decide whether to set FLAG_CONST on the index variable
is based on isReferenceType() of _indexOfInterest and,
in the case it is detupled, on isReferenceType() of the
corresonding tuplel component.

Looking in the future: A solution based on FLAG_REF_VAR
would be preferred. Each index variable would be either
FLAG_CONST or FLAG_REF_VAR. FLAG_REF_TO_CONST would be
added to the latter if appropriate.

I set FLAG_INDEX_OF_INTEREST on temporaries to handle the case
of the index variables forming a tuple of a tuple, e.g.

  for ((i1,i2),a) in zip(my_2D_domain, myArray) ...

A tricky case is a zippered loop with a 'var' iterator,
and a single index variable, i.e. with no detupling:

  for myVar in zip(...) ...

Ideally we would like myVar(i) to be mutable for those
'i' positions that correspond to mutable iterators,
and const for the other positions.

Currently, in the above, myVar is considered 'const'.
I hope this makes sense.
All myVar(i) are mutable, however, because checking
accesses to const tuples is not implemented.

Another tricky case is a regular loop where the iterator
returns a tuple containing an array. I did not look
into this case specifically.


On how _indexOfInterest is detupled:

The compiler currently creates a generic detupling expression
_indexOfInterest(1) etc. during parsing/in build.cpp.

During resolution this used to get converted to

(A) PRIM_GET_MEMBER i.e. address of _indexOfInterest(1)
if that member's type is non-reference

(B) PRIM_GET_MEMBER_VALUE if the member has a reference type

This actually makes sense. For (B) the address is fetched from the tuple
directly. This transports a Chapel-level reference.
For (A), the compiler did not specialize for _indexOfInterest.
In general, it is unknown whetherh myTuple(i) will be used
as a reference or as a value, to the more general choice
is made, and later transformations deal with this somehow.

For _indexOfInterest, however, we know that (A) will
be constant, so will not be used as a reference, so
we can use PRIM_GET_MEMBER_VALUE directly.
However, we still need to watch out when the entire
tuple has a _ref type, e.g. _ref(int*2). This indicates
that the tuple comes from a tuple-yielding 'var' iterator.
It so happens that we need PRIM_GET_MEMBER in this case.

The same applies to chpl__followIdx because it serves
the same purpose, except in forall loops.

My motivation for this change is that I need it for my
upcoming forall intents.


TEST CHANGES

There were a couple of tests that assumed that index variables
are mutable. I modified them to comply with my checks.

Those tests seemed so convincing, however, that I feel
we should allows them optionally, e.g. using 'var' keyword:

  for myVar in ... // myVar is const
  for var myVar in ... // myVar can be modified

I filed a future for this. However, we may want to reconsider
whether the immutable should be the default.

A particular questionable case is iterating over tuple components
- should that be a 'var' iterator?

This resolves David's recent future on the subject. I augmented .good
because the compiler reports both const errors in a single pass.

This introduces a regression in

  types/tuple/sungeun/iteration/forall.chpl

because the code modifies a 'const' loop variable.
We need to see how to fix this.
Reverted bdde6f0 and 9b25728 - essentially reverting ~/b/PATCH.detuple-v5-withCC.compiler and  ~/b/PATCH.detuple-v5-withCC.source-changes
Merged chapel-lang/master