Compilation failure for promotion and named-expression

[benharsh]

Summary of Problem

The following program fails to compile due to the use of a named-expression in a promoted expression:

proc foo(a:int=1, b:int=2) {
  return a + b;
}

var A = [1,2,3,4,5];
var X = foo(1, b=A); // Compiles and runs successfully.
writeln(X);
var Y = foo(b=A); // Fails to compile
writeln(Y);

The compiler fails with the output:

foo.chpl:8: error: unresolved call 'chpl_iteratorFromForExpr()'
$CHPL_HOME/modules/internal/ChapelIteratorSupport.chpl:217: note: candidates are: chpl_iteratorFromForExpr(ir: _iteratorRecord)
$CHPL_HOME/modules/internal/ChapelIteratorSupport.chpl:225: note:                 chpl_iteratorFromForExpr(arg)

[benharsh]

@vasslitvinov : here's the bug we briefly emailed about.

Edit: it is not blocking me in any way.

[cassella]

The behavior has changed to

foo.chpl:8: internal error: assertion error [resolution//home/fortytwo/src/chapel/compiler/resolution/wrappers.cpp:2063]

which is

static Symbol* leadingArg(PromotionInfo& promotion, CallExpr* call) {
  int i = promotion.formalToActualOpMod;
  // Operators might have a different number of formals than provided actuals.
  // In this case, the promotedType array access needs to be adjusted to account
  // for the offset.
  for_actuals(actual, call) {
    if (i < 0) {
      i++;
      continue;
    }
    if (promotion.promotedType[i++] != NULL)
      return symbolForActual(actual);
  }

  INT_ASSERT(false); // did not find any promoted things
  return NULL;
}

[bradcray]

If the assertion is removed, it seems like the behavior is very similar to that in the OP, so maybe not much has changed here... :(

[DanilaFe]

Since Michael mentioned it would be nice to get this working in Dyno, I've double checked that it works (it does!). #26464 locks down the test (though it does not fix the issue in production).