Chapel: export proc empty does not compile

[mppf]

export proc empty() { }
empty();

does not compile, with C backend errors.

[ben-albrecht]

FYI @npadmana (who originally discovered this bug)

[bradcray]

I was curious what the cause was here, as it seemed likely to be mine, and it turns out it is. The following is from a comment in compiler/codegen.cpp in the protectNameFromC() routine that explains what's going on (the second instance of empty() is from an internal module, specifically ChapelError.chpl.

  //                                                                            
  // For now, we only rename our user and standard symbols.  Internal           
  // modules symbols should arguably similarly be protected, to ensure          
  // that we haven't inadvertently used a name that some user library           
  // will; most file-level symbols should be protected by 'chpl_' or            
  // somesuch, but of course local symbols may not be, and can cause            
  // conflicts (at present, a local variable named 'socket' would).             
  // The challenges to handling MOD_INTERNAL symbols in the same way            
  // today is that things like chpl_string and uint64_t should not be           
  // renamed, and should arguably have FLAG_EXTERN on them; however,            
  // putting it on them causes it to bleed over onto type aliases in a          
  // way that breaks things and wasn't easy to fix.  So this remains            
  // a TODO (currently in Brad's court).                                        
  //                                                               
  ModuleSymbol* symMod = sym->getModule();
  if (symMod->modTag == MOD_INTERNAL) {
    return;
  }

It'd probably be worth my while to check this again and see whether the world
has changed enough since it was written to enable it; and if not, whether we could
use a narrower filter than "is in an internal module" to work around those cases
that are problematic.

[bradcray]

I've got a five-minute fix (TM) for this that is looking promising...

[bradcray]

I'm reopening this because my approach broke LLVM compilation, so I the bug still remains when using --llvm.

[bradcray]

When @mppf gets back, I'm hoping he might have some time to help me understand what's going on with the --llvm behavior (maybe as a potential teaching moment about using the LLVM back-end).