First stab at a directory-specific walker
Oops, accidentally committed this on master
Added const-ness checking for loop index variables
Merge branch 'master' of https://github.com/bradcray/chapel
Merge branch 'master' of https://github.com/chapel-lang/chapel
Test for sorter[ator]() iterator
Merge branch 'master' of https://github.com/chapel-lang/chapel into sorterator
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.
Added FLAG_INDEX_OF_INTEREST in one other case.
While there, also moved a couple of newTemp() allocations
to where they are used.
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]
Merge branch 'master' of https://github.com/chapel-lang/chapel
Merge branch 'sorterator' of https://github.com/bradcray/chapel
Changing sorter() to sorted()

Thomas pointed out that Python uses sorted() for a generator like
this, which also happens to be the first name I used before deciding
that it sounded like a boolean query rather than an iterator.
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.
Merge branch 'master' of https://github.com/chapel-lang/chapel
Merge pull request #336 from bradcray/sorterator

First draft sorterator

[reviewed by @thomasvandoren]

This is a first draft of a sorterator -- an iterator that takes some
other iterator or iterable as input, captures it into an array, sorts
it, and yields the elements back out to the user.  The current
limitations in the implementation reflect limitations in the language:

(1) There's no particularly good way to constrain the formal type to
be an iterator or iterable;

(2) There's no particularly good way to declare the type of the
temporary array;

Also added a test that invokes the sorterator in three ways, one with
an array, two with invocations of iterators.