[chapel-lang/chapel] Start resolving methods by also always looking at

Notifications Commits
1

Branch: refs/heads/master
Revision: ea9a7bd
Author: lydia-duncan
Log Message:

Merge pull request #16208 from lydia-duncan/funcResMethods

Start resolving methods by also always looking at the type’s definition point
[reviewed by @vasslitvinov and @daviditen]

Sometimes we have access to a type instance in situations where we can’t follow use
or import statements back to the original type definition (for instance, if the instance
was returned to us by a function that contained the use within its body). Such
situations should not prevent us from utilizing the type, at least to the extent that
is possible from the original scope (accessing secondary methods in other modules
should still require a use of that module, though).

This PR makes that possible, by allowing function resolution to directly search the
scope in which the type was defined.

Resolves #15946
Resolves Cray/chapel-private#1217

This does not replace the strategy added from last release (allowing us to search
private uses and imports regardless of their scope), but it enables us to do so if that
ends up being the conclusion of #16183 (which seems likely).

Note: we don’t expect this to be relevant to type methods, as in order to reference them
the code will need to have access to the type name regardless.

Updates eight tests:

  • Rearranges the expected candidates for the error messages of three tests
  • Updates the expected behavior for four tests that now compile and run that previously
    failed with an error message
  • Changes a future that wanted an error message to accept the successful compilation
    and execution.

Adds some new tests of the functionality, spawned off a simplified version of the
failure in #15946:

  • Checks returning an instance and storing it in a field, then calling a method on that
    field in another context
  • Similar to the previous, but the method is actually inherited from a parent type
  • Similar to the previous two, but the method is an override of one defined on the
    parent type and the field’s declared type is of the parent type (to ensure we
    dynamically dispatch correctly)
  • Similar to the first, but instead of printing the method returns a param (which is
    printed later)

Passed a full paratest with futures

Modified Files:
A test/functions/generic/poi/fieldDifferentMod-returnParam.chpl
A test/functions/generic/poi/fieldDifferentMod-returnParam.good
A test/functions/generic/poi/fieldDifferentMod.chpl
A test/functions/generic/poi/fieldDifferentMod.good
A test/functions/generic/poi/fieldDifferentModDynamicDisp.chpl
A test/functions/generic/poi/fieldDifferentModDynamicDisp.good
A test/functions/generic/poi/fieldDifferentModInheritance.chpl
A test/functions/generic/poi/fieldDifferentModInheritance.good
R test/modules/diten/returnRecordDiffModule.future
M compiler/resolution/visibleFunctions.cpp
M test/classes/generic/typeOfGenericField-fromTypeVariable.bad
M test/distributions/ferguson/dist-assoc-bulkadd.bad
M test/modules/diten/returnClassDiffModule.chpl
M test/modules/diten/returnClassDiffModule.good
M test/modules/diten/returnClassDiffModule6.chpl
M test/modules/diten/returnClassDiffModule6.good
M test/modules/diten/returnRecordDiffModule.good
M test/modules/diten/testOpaqueClass.chpl
M test/modules/diten/testOpaqueClass.good
M test/modules/diten/testOpaqueClass2.chpl
M test/modules/diten/testOpaqueClass2.good
M test/types/partial/match-param.bad

Compare: https://github.com/chapel-lang/chapel/compare/9967b85f7ac4...ea9a7bd69359