Overloading paren-less vs. paren-ful routines should result in an ambiguity error

[bradcray]

Summary of Problem

For years, I've been mistakenly thinking and saying that Chapel would give an ambiguity error when a program contains overloads of a routine with and without parenthesis since, in cases like the following, there's no clear answer as to which routine should be called:

proc foo {
  return [1.0, 2.0];
}

proc foo(x: int) {
  return x+1;
}

writeln(foo(1));

However, in Chapel 1.24.1 and a few other versions I've checked back to Chapel 1.10.0, I'm finding that instead it just arbitrarily picks one of them (seemingly whichever overload is defined second?). This seems problematic to me since it can represent confusion on the part of a user and is somewhat similar to overloading a variable and a procedure or a field and a method.

It can also come up in more subtle cases like class hierarchies:

class C {
  proc foo {
    writeln("In C.foo");
  }
}

class D: C {
  proc foo(x: int) {
    writeln("In D.foo");
  }
}

var myD = new D();
myD.foo(1);

where it seems we pick the parent class method.

Configuration Information

• Output of chpl --version: chpl version 1.25.0 pre-release (2bf652fc09)

[mppf]

I'm finding that instead it just arbitrarily picks one of them (seemingly whichever overload is defined second?)

That is odd.

We could consider fixing this bug in the new resolver and leaving the old resolver. I'm somewhat worried that the current behavior (at least in the case where the order matters) is relying on some interaction between scope resolution and function resolution that might be hard to tease out).

[bradcray]

I'm going to look into what it would take to fix it in the current compiler as I think it's pretty terrible behavior, and suspect it could be low-hanging fruit. Specifically, I'm not sure it is a scope resolution vs. function resolution issue. E.g., here's the --explain-call output for the orderings of the functions for the code in the OP:

testit.chpl:11: note: call: foo(1)
testit.chpl:1: note: visible functions are: foo [210494]
testit.chpl:6: note:                        foo(x: int) [210535]
testit.chpl:6: note: candidates are: foo(x: int) [210535]
testit.chpl:6: note: best candidate is: foo(x: int) [210535]

[bradcray]

Ah, but I think you're right that the fact that the order matters probably implies that scopeResolve is involved. But it also makes me think that it shouldn't be too difficult to make scopeResolve treat both cases the same since function resolution sees both versions above.

[bradcray]

I'm closing this issue because the first case has gotten better in dyno, and the second case is different / unique enough (while also having seemingly changed behavior) that I forked it off into its own issue (#22768). That said, there is also an inconsistency between overloaded methods with different paren-ful-ness when defined within a type, which I've forked into #22767.