Introduce While/For loop as a thin veneer over BlockStmt
Convert While/For build functions to class methods on the new classes
Convert remaining uses of ForLoop from BlockStmt to ForLoop veneer in build.cpp
Update a function name to suppress a GCC warning
Merge pull request #670 from noakesmichael/loopWrap-1

While/For loop veneer

This is the first step in introducing new AST nodes for WhileDo, DoWhile, For, and CFor loops.
The first implementation is a very thin wrapping over BlockStmt.  There is no new state only
new constructors and a few simple methods.  This is the anchor point for adding a reasonably
robust interface layer to these AST nodes across the code base.  Once that is done it will be
practical to refine the internal representation.

There is little "new code" here.  Most code has been migrated from other places e.g.
copying simple code from BlockStmt and from build.cpp

Elliot has performed a sanity check on this code but did not perform a
careful code review given that is largely refactoring of existing code.

Compiled: Std clang on Mac, Std gcc on Liinux, LLVM gcc on Linux
Testing: Full regression suite  std+verify, llvm+verify
Fix NUMA build failure.

Application of FLAG_COMPILER_GENERATED caused locale.name to be selected in favor of
NumaDomain.name.  Assignment to this in the constructor then looked like an attempt to
write to an rvalue, so the Chapel compiler flagged it as an error.

I decided to back out the change.  It seems like in general a user wants the local field
name to bind at least as tightly as an inherited getter.  The compiler generates getter
and setter functions only if they are not provided by the user, so the "compiler
generated" flag is not really needed in this case.

I also backed out the change to classes/diten/nearestMutualParentClass, as the "compiler
generated" pragma is no longer needed there.
Migrate the codegen code from BlockStmt to the new Loop ASTs
Add a test case to show that getters in derived classes dominate.
Merge pull request #671 from hildeth/master

Fix NUMA build failure.

Application of FLAG_COMPILER_GENERATED caused locale.name to be selected in favor of
NumaDomain.name. Assignment to this in the constructor then looked like an attempt to
write to an rvalue, so the Chapel compiler flagged it as an error.

I decided to back out the change. It seems like in general a user wants the local field
name to bind at least as tightly as an inherited getter. The compiler generates getter
and setter functions only if they are not provided by the user, so the "compiler
generated" flag is not really needed in this case.

I also backed out the change to classes/diten/nearestMutualParentClass, as the "compiler
generated" pragma is no longer needed there.

This patch passes all but 6 multilocale tests with CHPL_LOCALE_MODEL=numa and CHPL_GASNET_SEGMENT=fast.  There are known comm-count differences in distributions/robust/arithmetic/performance/multilocale/
  reduceAlias
  reduceSlice
  reduce
There are also known sporadic timeouts in distributions/robust/arithmetic/
  modules/test_module_Sort
  slicing/test_array_slicing3
The remaining test 
  basics/test_zipper_default
now times out consistently on the test machine I was using (chap01).
Add some printfs to verify that the LLVM BlockStmt::codegen() isn't being used for Loops
Merge pull request #672 from noakesmichael/loopWrap-2

Move loop codegen from BlockStmt to new AST nodes

Compiled: STD clang on mac, STD gnu on linux, LLVM gnu on linux
Tested: Full paratest with STD --verify and LLVM --verify
Reviewed: None
1) Improve the interface for constructing ForLoops  2) Remove the legacy elements of codegen from BlockStmt
Merge pull request #673 from noakesmichael/loopWrap-3

Minor changes for While/For loops

1) Add new constructors to ForLoop to improve the interface to builder code

2) Remove the For/While loop codegen code from BlockStmt

Compiled: clang std  on Mac,  gcc std/llvm on Linux
Testing: full paratest with STD --verify and LLVM --verify
Review: None
Update record_from_string.bad file.

This is an improvement resulting from PR#667.

Because FLAG_COMPILER_GENERATED was not attached to the compiler-generated record
assignment function, the assignment type mismatch error was attributed to the first line
of the record definition (line 1) rather than the line on which it is invoked (line 11).
Now the error is attributed to the user source code line that causes it, which is at once
more accurate and more useful.
Remove a passing .future

Hildeth's commit 81ad381c6ef98e84e90d7d4ac49dbff57dd87ad4 marked compiler
generated destructors with FLAG_COMPILER_GENERATED, so object.~chpl_destroy no
longer shows up as a candidate function in the error message in this test.
Merge pull request #674 from hildeth/master

Update record_from_string.bad file.



This is an improvement resulting from PR#667.

Because FLAG_COMPILER_GENERATED was not attached to the compiler-generated record
assignment function, the assignment type mismatch error was attributed to the first line
of the record definition (line 1) rather than the line on which it is invoked (line 11).
Now the error is attributed to the user source code line that causes it, which is at once
more accurate and more useful.
Merge pull request #675 from daviditen/removePassingDestructorFuture

Remove a passing .future

Hildeth's commit 81ad381 marked compiler
generated destructors with FLAG_COMPILER_GENERATED, so object.~chpl_destroy no
longer shows up as a candidate function in the error message in this test.