[Chapel Merge] compiler/next: canInstantiate and getInstantiation

Notifications Commits
1

Branch: refs/heads/main
Revision: 32b71c4
Author: mppf
Link: compiler/next: canInstantiate and getInstantiationType by mppf · Pull Request #18822 · chapel-lang/chapel · GitHub
Log Message:

Merge pull request #18822 from mppf/next-instantiations

compiler/next: canInstantiate and getInstantiationType

This PR continues the effort of filling in canInstantiate and
getInstantiationType logic for the compiler/next prototype resolver.

In particular it:

  • in can-pass.h / can-pass.cpp:
    • moves isSubtype to include canPassSubtype since some subtype
      conversions also instantiate so we'd like to be able to track that
    • adds canInstantiateBuiltin and canInstantiate helpers to handle
      some of the cases
    • adds checks for subtype for class conversions
    • fixes param formals with unknown value as needing instantiation
    • adds logic in canPass to handle the variety of intents (e.g. out,
      inout) and to consider generic formals
  • in types/
    • adds instantiatedFrom to CompositeType and children
    • adds isSubtypeOf and instantatedFrom helpers in BasicClassType
    • adds instantiatedFromCompositeType and isInstantiationOf helpers to
      CompositeType
    • renames isAnyPtrType to isPtrType, isAnyNilablePtrType to
      isNilablePtrType to reduce confusions with typed named things like
      AnyType.
    • adds isUserRecordType
    • adds a few builtin types that were overlooked so far
  • in resolution-queries.h / resolution-queries.cpp:
    • renames typeForTypeDecl to initialTypeForTypeDecl to reflect that
      the final type might be a result of instantiation and to better
      match the initial / instantiated terminology for functions
    • resolves parent class types
    • adds an implementation of getInstantiationType
    • uses canPass result including instantiation to decide when to add a
      substitution for a formal
    • handle more cases in the resolveIntent implementation

Future work: Look into recursive type declarations & better factor the
repeated calls to the struct Resolver.

Reviewed by @dlongnecke-cray - thanks!

  • [x] full local testing

    Modified Files:
    M compiler/next/include/chpl/resolution/can-pass.h
    M compiler/next/include/chpl/resolution/resolution-queries.h
    M compiler/next/include/chpl/resolution/resolution-types.h
    M compiler/next/include/chpl/types/BasicClassType.h
    M compiler/next/include/chpl/types/CompositeType.h
    M compiler/next/include/chpl/types/RecordType.h
    M compiler/next/include/chpl/types/TupleType.h
    M compiler/next/include/chpl/types/Type.h
    M compiler/next/include/chpl/types/TypeClassesList.h
    M compiler/next/include/chpl/types/UnionType.h
    M compiler/next/lib/resolution/can-pass.cpp
    M compiler/next/lib/resolution/resolution-queries.cpp
    M compiler/next/lib/types/BasicClassType.cpp
    M compiler/next/lib/types/RecordType.cpp
    M compiler/next/lib/types/TupleType.cpp
    M compiler/next/lib/types/Type.cpp
    M compiler/next/lib/types/UnionType.cpp
    M compiler/next/test/resolution/testCanPass.cpp
    M compiler/next/test/resolution/testResolve.cpp
    M compiler/next/test/resolution/testTypeConstruction.cpp

    Compare: Comparing df5688a73ca9...32b71c46fa5e · chapel-lang/chapel · GitHub