[Chapel Merge] dyno: improve detection of generic fields without

Notifications Commits
1

Branch: refs/heads/main
Revision: 5ecd68a
Author: DanilaFe
Link: dyno: improve detection of generic fields without defaults. by DanilaFe · Pull Request #20301 · chapel-lang/chapel · GitHub
Log Message:

Merge pull request #20301 from DanilaFe/change-genericity-computation-v2

dyno: improve detection of generic fields without defaults.

Dyno does not instantiate generic records in
which some generic fields lack defaults. However, the means by
which Dyno determines if a type has defaults for each generic
field is flawed. It proceeds by resolving fields while ignoring all
defaults / initializers, and then checking if all of the resolved fields
that are generic have defaults. However, in this way, a field can
be marked "maybe generic" and prevent instantiation even though
it does not itself require a default value.

A simple example is as follows.

proc id(type t) type return t;

record r {
  type typeWithDefault = int;
  var nonGenericField : id(typeWithDefault);
}

The record r is generic. The default value specified for
typeWithDefault should be sufficient to instantiate r with defaults;
once typeWithDefault is determined, the type of nonGenericField can
be computed to be int, and no further information is needed. However,
when ignoring all defaults when resolving fields, typeWithDefault
is marked as AnyType, and the call to id is resolved to have type
Unknown. In this way, nonGenericField is considered to be
MAYBE_GENERIC, and, since it doesn't have a default value, Dyno refuses
to default-instantiate r.

This commit adjusts this behavior by adding a new mode for resolving
fields. In this mode, instead of ignoring the default value /
initializer of all fields in a record, only the current field's default
is ignored. In this way, it becomes possible to determine whether or not
a field would be generic if the fields it depends on are provided with
default values, or if it itself also needs a default.

This also contributes towards resolving the range record from the
Chapel standard library, since it too has non-generic fields whose
type expressions refer to functions in the ChapelRange module.

Reviewed by @mppf - thanks!

Testing:

  • paratest

    Modified Files:
    A compiler/dyno/test/resolution/testGenericDefaults.cpp
    M compiler/dyno/include/chpl/resolution/resolution-queries.h
    M compiler/dyno/include/chpl/resolution/resolution-types.h
    M compiler/dyno/lib/resolution/Resolver.cpp
    M compiler/dyno/lib/resolution/Resolver.h
    M compiler/dyno/lib/resolution/default-functions.cpp
    M compiler/dyno/lib/resolution/resolution-queries.cpp
    M compiler/dyno/test/resolution/CMakeLists.txt
    M compiler/dyno/test/resolution/testTypeConstruction.cpp

    Compare: Comparing d6fa829809c8...5ecd68ac9160 · chapel-lang/chapel · GitHub