[Chapel Merge] Dyno: allow `out` to initialize `const` variables, enable split-init of generic types

Notifications Commits
1

Branch: refs/heads/main
Revision: 37d5199f5ed31ad94ff40e8c3224292925f56a1a
Author: DanilaFe
Link: Dyno: allow `out` to initialize `const` variables, enable split-init of generic types by DanilaFe · Pull Request #28038 · chapel-lang/chapel · GitHub
Log Message:
Dyno: allow out to initialize const variables, enable split-init of generic types (#28038)

Depends on Dyno: stop emitting internal errors when trying to invoke enum types by DanilaFe · Pull Request #27986 · chapel-lang/chapel · GitHub,
Dyno: add `extern` block pointer support to dyno by DanilaFe · Pull Request #27990 · chapel-lang/chapel · GitHub,
Dyno: distinguish between "fully" and "partially" generic formals. by DanilaFe · Pull Request #27993 · chapel-lang/chapel · GitHub,
https://github.com/chapel-lang/chapel/pull/28006, and
Dyno: good file updates for recent merges by DanilaFe · Pull Request #28037 · chapel-lang/chapel · GitHub.

Closes https://github.com/Cray/chapel-private/issues/7663.

This PR makes some improvements to split initialization and const
checking. Specifically, it tackles a few issues:

  • const variables that were split-initialized using out formals
    were not properly handled    . This was because const checking didn't
    recognize variable initialization as a special case in which assigning
    to a const variable is allowed. To robustly detect cases where split
    initialization takes place, I lean on associated actions for
    initialization. However, we didn't add associated actions in all cases.
    In particular, move-initialization was not tracked because it does not
    cause any resolution. So, add a new "move init" associated action, tag
    resolved expressions with it, and don't const-check actuals with the
    relevant associated actions.
  • Variables with generic types could not be out-initialized. This
    affected cases like var x: numeric; foo(x). To this end, adjust the
    logic for skipping calls to allow generic values regardless of
    "eagerness" (see https://github.com/chapel-lang/chapel/pull/28006) when
    they can be split-initialized.
  • In making these changes, observe that @arezaii's split-init message
    from https://github.com/chapel-lang/chapel/pull/26497 expects a narrower
    definition of "actual that isn't out-initialized but needs to be" than
    we now have (specifically, it singles out "variables without type
    expressions"). In general, it seems hard to distinguish actuals that
    were passed in as part of an out-init workaround from ones that
    aren't. Instead of adjusting Ahmad's heuristic, adjust CallInfoActual
    to carry a boolean flag for whether it requires initialization. Then,
    specialize and tweak the error message.
  • In doing that, observe that the formal-actual map was using "excess
    actuals" to compute the number of vararg formals, and as a result was
    estimating too few vararg actuals when formals with defaults were
    present. Adjust alignment computation for this case. In general, I am
    beginning to think we might need to use type information more heavily to
    compute the FAMap during instantiation, but this is a relatively cheap
    stopgap.
  • Also, I noticed that although I made the test referenced in
    https://github.com/Cray/chapel-private/issues/7663 pass some time ago,
    the sample code in the issue still didn't compile. It turns out that in
    general, we were not checking formal-actual mappings when using
    compiler-generated concrete type constructors. Thus, record R {}; R(...args....) worked for any args, until disambiguation, when it
    would fail. This PR 1) adjusts the type constructor logic to do initial
    signature checking in addition to instantiation checking 2) makes tweaks
    to doIsSignatureApplicableInitial to narrow the scope of special cases
    etc (some of which were overzealously applied to type constructors, or
    resulted in weird behavior).

Reviewed by @benharsh -- thanks!

Testing

  • dyno tests
  • paratest
  • paratest --dyno-resolve-only

Compare: Comparing c6b6c3fa673ab7207e249501e5447269960e33ae...c3ab40fb2a45a8836658376fc855273173e2e471 · chapel-lang/chapel · GitHub

Diff:
M frontend/include/chpl/resolution/resolution-types.h
M frontend/lib/resolution/Resolver.cpp
M frontend/lib/resolution/Resolver.h
M frontend/lib/resolution/call-init-deinit.cpp
M frontend/lib/resolution/maybe-const.cpp
M frontend/lib/resolution/resolution-error-classes-list.cpp
M frontend/lib/resolution/resolution-queries.cpp
M frontend/lib/resolution/resolution-types.cpp
M frontend/lib/types/QualifiedType.cpp
M frontend/test/resolution/testCallInitDeinit.cpp
M frontend/test/resolution/testConstChecking.cpp
M frontend/test/resolution/testResolverVerboseErrors.cpp
M frontend/test/resolution/testSplitInit.cpp
M frontend/test/resolution/testTypeConstruction.cpp
M util/misc/dyno-ignore-good-files.patch
https://github.com/chapel-lang/chapel/pull/28038.diff