Branch: refs/heads/main
Revision: 319a9d5a59611a270fcdb792e555457a8c3c421b
Author: DanilaFe
Link: Dyno: fix infinite recursion caused by `init=` on "core" types. by DanilaFe · Pull Request #26642 · chapel-lang/chapel · GitHub
Log Message:
Dyno: fix infinite recursion caused by init= on "core" types. (#26642)
Closes https://github.com/Cray/chapel-private/issues/7069.
Bundles Apply Ben's numerous minor fixes by DanilaFe · Pull Request #26641 · chapel-lang/chapel · GitHub (clean diff
IOU) to get at the heart of the issue.
There are two minor issues causing the bug.
- We resolved
init=two times (once fromMostSpecificCandidate, see
Dyno: implement `compilerError` and `compilerWarning` by DanilaFe · Pull Request #26613 · chapel-lang/chapel · GitHub) and once in
resolveFnCall. The latter call was redundant and is vestige of an
older version of the resolver. - The second
init=call did not guardskipIfRunninglike most other
calls, and thus didn't circumvent recursion errors. However, since its
purpose was to emit diagnostics from theinit=body, it's sound to
skip recursive calls, since the outer call will still issue these
diagnostics.
Since this code is redundant, I simply removed it. Triggering the issue
in Dyno without prod was a little challenging (it's important that PoI
information is not used, which means the call to functions in init=
needs to be fully concrete and not an instantiation).
Reviewed by @benharsh -- thanks!
Testing
- dyno tests
- paratest
Diff:
M compiler/include/driver.h
M compiler/main/driver.cpp
M frontend/lib/resolution/call-graph.cpp
M frontend/lib/resolution/default-functions.cpp
M frontend/lib/resolution/resolution-queries.cpp
M frontend/lib/resolution/resolution-types.cpp
M frontend/test/resolution/testInitSemantics.cpp
https://github.com/chapel-lang/chapel/pull/26642.diff