New Issue: Resolution failures should not show standalone function/method candidates that don't apply

Notifications Issues
1

16928, “bradcray”, “Resolution failures should not show standalone function/method candidates that don’t apply”, “2021-01-11T19:19:02Z”

As a Chapel programmer, I believe that the compiler’s resolution error messages would be clearer to understand if they did not list method candidates for a callsite that is necessarily a standalone function; nor standalone method candidates for a callsite that is necessarily a method call. For example, in issue #16917, @rchinmay’s call to write() lists various .write() methods on atomic types as candidates even though the call was standalone. I find that in most cases, such candidates make the compiler’s error messages less clear rather than more.

To that end, I’d be inclined to say:

  • for a call myExpr.foo(), we only list methods named foo() as candidates (or maybe better, only methods named foo() that are within the class hierarchy of myExpr's static type?)
  • for a call foo() that is being made outside of a method context, we only list module-scope routines as candidates
  • for a call foo() that is being made within a method context, we list both method and standalone candidate routines (where any filtering for “which methods” in bullet 1 above would apply)

If there were concern that this swept too much under the rug (e.g., maybe the user wrote foo() but meant to type x.foo()?), perhaps the compiler could support a flag like --print-all-candidates that would override this filtered behavior (and perhaps the default error message could refer to the flag? though I probably wouldn’t do that until we knew it was causing programmers to miss things).