[Chapel Merge] CLS: display auto-computed instantiations for procedures that are only generic because of array formals

Notifications Commits
1

Branch: refs/heads/main
Revision: 99e2811bfae80327d50f6d927701cb583c68cc3e
Author: DanilaFe
Link: CLS: display auto-computed instantiations for procedures that are only generic because of array formals by DanilaFe · Pull Request #28502 · chapel-lang/chapel · GitHub
Log Message:
CLS: display auto-computed instantiations for procedures that are only generic because of array formals (#28502)

This PR stemmed from my attempt to use CLS with the Mason codebase.

The main trouble with the mason codebase is that nearly every module is
written in terms of a main (not main) function that just accepts the
CLI arguments for the sub-command, like masonUpdate([] string). The
trouble with functions like this is that under the current semantics of
Chapel, they are generic. Without any calls to instantiate them[1],
they are left entirely generic and no useful information is shown in the
editor.

This PR improves on this situation by detecting procedures that are only
generic due to their array formals, and computed an instantiation of
these procedures with the generic formals instantiated with
default-rectangular array types. This works as follows:

  • For array formals with the type [] eltType, which can be any rank,
    we arbitrarily pick a rank of 1, and compute a one-dimensional
    default-rectangular domain with which to create the array. This is
    handled by computeDefaultBoundedRange,
    computeDefaultRectangularDomain, and computeDefaultRectangularArray.
  • For array formals with an explicit domain expression, we create an
    instantiation of a matching rank. This is handled by
    rebuildDomainInstance and computeDefaultRectangularArray.

The result:

Screenshot 2026-03-05 at 3 32 10 PM
Screenshot 2026-03-05 at 3 32 10 PM652×244 19.3 KB

Screenshot 2026-03-05 at 3 32 43 PM
Screenshot 2026-03-05 at 3 32 43 PM1246×232 28.6 KB

Reviewed by @jabraham17 -- thanks!

Testing

  • dyno tests
  • CLS tests

Compare: Comparing d3c8a88f29838df16ef8117bf9db70afbb898434...87e13e3a9f7c9b65b884e283fced0edfb791ec5d · chapel-lang/chapel · GitHub

Diff:
M frontend/lib/resolution/Resolver.cpp
M tools/chapel-py/src/method-tables/core-methods.h
M tools/chapel-py/src/method-tables/uast-methods.h
M tools/chapel-py/src/resolution.cpp
M tools/chapel-py/src/resolution.h
M tools/chpl-language-server/src/chpl-language-server.py
M tools/chpl-language-server/src/lsp_util.py
M tools/chpl-language-server/test/show_generic.py
https://github.com/chapel-lang/chapel/pull/28502.diff

  1. Technically, the main procedure from Mason calls the functions and
    instantiates them. However, two pieces are missing for that to be
    reflected in CLS: for one, cross-file instantiations are not collected,
    and for another, we'd still need to default-instantiate the main proc
    with a one-dimensional, default-rectangular array of strings. ↩︎