[chapel-lang/chapel] Resolves #15948.

Notifications Commits
1

Branch: refs/heads/master
Revision: c484864
Author: vasslitvinov
Log Message:

Modification of the POI rule (#16158) by vasslitvinov

Resolves #15948.

This implements the change in the POI visibility rule, as discussed in
#15948 . Specifically, when gathering resolution candidates for a call:

  • Select applicable candidates among functions visible from the scope
    of the call itself, including functions reachable through import and
    use statements. When the call is in a concrete function, this is the
    only step that happens; it remains unaffected by this PR.

  • If no applicable candidates are found so far and the call is in a
    generic function GF1, repeat the above step using POI of the generic
    function GF1 instead of the call.

  • If still no applicable candidates are found and POI of GF1 is itself
    in a generic function GF2, repeat the above step using POI of GF2.

  • Continue this process of traversing POIs until the current POI
    yields applicable candidates or the current POI is in a concrete function.

  • In the above process, do not include functions labeled with pragma
    “last resort”. If all POIs, if any, are exhausted and still still no
    applicable candidates are found, repeat the process, this time
    considering only “last resort” functions, if any. It is the (LR-2) option in
    https://github.com/chapel-lang/chapel/issues/15948#issuecomment-667334488

The difference from the previous behavior is in checking for
applicable candidates before proceeding to the [next] POI. Previously
there was a single pool of visible functions that combined those
visible from the call plus those visible from each POI. Applicable
candidates were selected from this pool. Now, the [next] POI is
consulted only when no applicable candidates are found without it.

Test changes

Implementation details

The iteration over POIs is done in findVisibleFunctionsAndCandidates().
Because it invokes the distinct helpers to (a) collect visible functions and
(b) from those, extract applicable candidates.

Last-resort visible functions are gathered at the same time to avoid
spending extra compilation time to traverse the scopes again. numVisitedLRC
helps examine last-resort visible functions for one POI at a time.

It took effort to retain the existing behavior upon an unresolved
call. In particular, error reporting machinery needs access to visible
functions across all POIs. For example, if there are functions visible
from the scope of the call, none of them applicable candidates, we
still need to remember those. This is needed to report them if we
traversed POI(s) and either still did not find applicable candidates
or need to --explain-call.

Because of that the vectors visibleFns and mostApplicable still
collect visible functions for the call and all POIs, as before. I also
made an adjustment to --explain-call code to avoid multiple occurrences
of “note: call +(int,int)” and premature “no visible functions found”.

While there, added some debugging tools to view.cpp.

Some development history is at 861c8044e9…2566185c94

Reviewed by @mppf

Modified Files:
R test/functions/ferguson/hijacking/Application4.bad
R test/functions/ferguson/hijacking/Application4.future
M compiler/AST/view.cpp
M compiler/include/view.h
M compiler/include/visibleFunctions.h
M compiler/resolution/functionResolution.cpp
M compiler/resolution/visibleFunctions.cpp
M test/functions/ferguson/hijacking/Application4.chpl
M test/release/examples/benchmarks/shootout/meteor-fast.chpl
M test/studies/comd/elegant/arrayOfStructs/util/AccumStencilDist.chpl
M test/studies/comd/elegant/arrayOfStructs/util/Simulation.chpl

Compare: https://github.com/chapel-lang/chapel/compare/575987571e61...c48486497af7