Removed checks and assertions upon form_Map.
Add a space after node ID (upon --gen-ids).
Merge pull request #987 from vasslitvinov/restore-space-in-generated-C-code

Add a space after node ID (upon --gen-ids).

There is often a space missing after the node ID in the generated code, e.g.:

  /* 889339*/ ret = type_tmp;

This space disappeared due to 23311c03 aka r20461, which commit
was unrelated:

+      info->cStatements.push_back("/* " + numToString(stmt->id) + "*/ ");
-    fprintf(outfile, "/* %7d */ ", stmt->id);

I am restoring this space for convenience highlighting in emacs
and for consistency.

Reviewed by Mike.
Merge pull request #986 from vasslitvinov/remove-checks-and-asserts-upon-form_Map

Removed checks and assertions used with form_Map().

The files createTaskFunctions.cpp and implementForallIntents.cpp
contained these idioms:

  form_Map(SymbolMapElem, e, ...) {
    INT_ASSERT(e->key);
    ...

and/or

  form_Map(SymbolMapElem, e, ...) {
    if (Symbol* sym = e->key) {
      ...

Since the 'form_Map' macro only yields non-NULL things by design,
the above assert and check are not needed. I am removing them.

I also replaced:      vars->put(sym, arg);
with the equivalent:  e->value = arg;
for efficiency.


These changes can also be applied to flattenFunctions.cpp.
I did not do so, to keep that code undisturbed.

Reviewed by Mike.
Fixed .bad mismatch for hplx.chpl.
Merge pull request #991 from vasslitvinov/fix--hplx.bad--mismatch

Fixed .bad mismatch for hplx.chpl.

This test has been failing in more and more diverse ways.
I keep relaxing PREDIFF to accept these failures, so I can have .bad
and match clean against it.

Or, Kyle suggests, maybe this test shouldn't have a .bad?
Change Filerator to use isLink(), isDir(), isFile()

Previously, I had been using my own home-cooked runtime query to
determine whether something was a file, a directory, or a symbolic
link.  Now that Lydia (and Francisco?) have provided utility
functions for this, I can use theirs and get rid of some (now-dead)
code.
Updating comment to re-trigger Travis build.

The previous Travis build broke, but not for reasons due to my code
changes, it seemed, so kicking it back off again and making this
comment a bit more crisp while here.
Filing a "method shadows local" scoping bug

This bug is similar to the one that Kyle filed in
test/functions/kbrady/proc_scoping.chpl in which a
(compiler-generated?) method from a standard/internal module is
shadowing a local variable.  Intuitively, it seems to me that methods
should never do this, suggesting scoping is broken.  Somewhat
maddeningly, I've been unable to determine (in the time I've spent on
it so far) the root cause of the shadowing symbol.  See the .future
for further details.
Moved 'use' of FileSystem to a more logical, but artificially scoped place

On Lydia's request, moved 'use' of FileSystem into a closer scope and
removed the fully-qualified references to isDir(), isFile(), isLink().
Added a comment explaining the use of the scope and referring to the
future I just filed.
Revise signature of function resolveBlock(Expr* block) to be resolveBlockStmt(BlockStmt* blockStmt)
Add function ParamForLoop* toParamForLoop(BaseAST* a)
Implement ParamForLoop::copy()
Implement a function that produces a copy of the body, a BlockStmt, of a ParamForLoop
Simplify BlockStmt::isLoopStmt()
Add a short-circuit for ParamForLoop to isDefinedAllPaths()
Clarify use of blockInfoGet() in is_param_resolved()
In fold_param_for 1) Clarify that block is in fact a ParamForLoop 2) Copy the body of the ParamForLoop as a BlockStmt
Merge pull request #992 from bradcray/globUseLydiasIsLink

Change Filerator to use isLink(), isDir(), isFile()

Previously, I had been using my own home-cooked runtime query to
determine whether something was a directory and/or a symbolic
link.  Now that Lydia (and Francisco?) have provided utility
functions for this, I can use theirs and get rid of some (now-dead)
code.

The only thing that's slightly ugly about my approach is how I
'use'd the FileSystem module.  I wanted to use it at the
procedure scope, but doing so seemed to shadow my 'path'
variable with a (compiler-introduced?) method of the same name.
So instead, I inserted an artificial innermost scope to contain
the 'use'.  This may be a short-term workaround because I think
that ultimately (once the names are finalized), these iterators
should be incorporated into the FileSystem module anyway
(at which point the 'use' will no longer be necessary).

I added a future demonstrating this surprise shadowing behavior.
I think it's similar to one that Kyle has submitted previously (noted
in the future itself).

Most of the diff here is (happily) dead code elimination.
Merge pull request #993 from noakesmichael/param-for-loop-3

Improve touch points between ParamForLoop and function resolution

1) There were places in resolve where a ParamForLoop was being "quietly" converted in to a BlockStmt;
some good, some bad.  Add copy() and copyBody() to do this in a more controlled manner

2) Fix up a couple f call sites that were calling blockInfoGet() on the propagated ParamForLoop


Compiled: STD clang/darwin, STD gcc/linux64, LLVM gcc/linux64
Tested: paratest --verify
Review: none