[Chapel Merge] dyno: (almost) resolve nontrivial ranges

Notifications Commits
1

Branch: refs/heads/main
Revision: fe5d5b4af3d518a59766cb1e0ed84c53b9b004d0
Author: DanilaFe
Link: dyno: (almost) resolve nontrivial ranges by DanilaFe · Pull Request #24853 · chapel-lang/chapel · GitHub
Log Message:
dyno: (almost) resolve nontrivial ranges (#24853)

This PR makes a few bugfixes that enable Dyno to resolve nontrivial
ranges. Closes https://github.com/Cray/chapel-private/issues/6102 in
favor of dyno: calls to initializers from other initializers aren't reflected. · Issue #24854 · chapel-lang/chapel · GitHub. Closes
dyno: can't write (secondary) generic initializers for non-special types · Issue #24811 · chapel-lang/chapel · GitHub. Closes
https://github.com/Cray/chapel-private/issues/4932. Closes
https://github.com/Cray/chapel-private/issues/6108.

To make all of this work:

  • Adds the 'none' keyword, which is used in a bunch of resolver
    functions. In doing so, moves both 'nil' and 'none' handling into the
    "builtin scope". In addition to make none work, this also fixes a
    (previously untracked) bug in which nil could not be found in
    initializers, since InitResolver didn't go through resolveIdentifier
    (where nil was handled), but did go through lookupIdentifier (where
    a not-found error was reported).
  • Adds support for defining secondary methods on generic-with-default
    types, and calling new on them. I actually don't remember why this
    blocked progress for ranges, but it's working now. To do this, I added a
    new "stack" to the resolver, which tracks any "should-be-generic"
    variables. This way, the genWithDefault identifier in init(this: genWithDefault...) is treated as generic, despite the usual logic in
    which it is instantiated. The same is done for new genWithDefault to
    make sure the generic instantiation type is passed to the initializer.
  • Fixes a bug in which AdjustMaybeRefs descended into nested functions
    and incorrectly access byPostorderId results with IDs from a different
    symbol. That led to some very interesting errors (functions reporting
    successful call, but formal-actual mismatch).
  • Make small tweaks to the standard library to work around Dyno's
    limitations that I don't fix in this PR.
    https://github.com/Cray/chapel-private/issues/6154

With this PR, the following program compiles (?!) with no errors.

var sum = 0;
for i in 1..#10 do sum += i;

The only trouble is that the by operator uses a range initializer that
causes another range initializer, which hits
dyno: calls to initializers from other initializers aren't reflected. · Issue #24854 · chapel-lang/chapel · GitHub. There are no errors,
but the stride is incorrectly reported.

Reviewed by @benharsh -- thanks!

Testing

  • dyno tests
  • paratest

Compare: Comparing c9c47c97346b9564b829da337765b8a2bcbcd7d9...5bc35722a7b83284d0649215c8d20d5db41a20d5 · chapel-lang/chapel · GitHub

Diff:
M frontend/lib/resolution/Resolver.cpp
M frontend/lib/resolution/Resolver.h
M frontend/lib/resolution/VarScopeVisitor.cpp
M frontend/lib/resolution/maybe-const.cpp
M frontend/lib/resolution/resolution-queries.cpp
M frontend/lib/resolution/scope-queries.cpp
M frontend/test/resolution/testMethodCalls.cpp
M frontend/test/resolution/testNew.cpp
M frontend/test/resolution/testRanges.cpp
M frontend/test/resolution/testResolve.cpp
M modules/internal/ChapelRange.chpl
https://github.com/chapel-lang/chapel/pull/24853.diff