Fix #12442.
The problem is described in the ticket. This patch adds new variants of the access points to the pure unifier that allow unification of types only when the caller wants this behavior. (The unifier used to also unify kinds.) This behavior is appropriate when the kinds are either already known to be the same, or the list of types provided are a list of well-typed arguments to some type constructor. In the latter case, unifying earlier types in the list will unify the kinds of any later (dependent) types. At use sites, I went through and chose the unification function according to the criteria above. This patch includes some modest performance improvements as we are now doing less work.
Showing
- compiler/ghci/RtClosureInspect.hs 1 addition, 1 deletioncompiler/ghci/RtClosureInspect.hs
- compiler/specialise/Rules.hs 2 additions, 2 deletionscompiler/specialise/Rules.hs
- compiler/typecheck/FunDeps.hs 4 additions, 4 deletionscompiler/typecheck/FunDeps.hs
- compiler/typecheck/TcSimplify.hs 3 additions, 3 deletionscompiler/typecheck/TcSimplify.hs
- compiler/types/Unify.hs 92 additions, 17 deletionscompiler/types/Unify.hs
- testsuite/tests/dependent/should_compile/T12442.hs 57 additions, 0 deletionstestsuite/tests/dependent/should_compile/T12442.hs
- testsuite/tests/dependent/should_compile/all.T 1 addition, 0 deletionstestsuite/tests/dependent/should_compile/all.T
- testsuite/tests/perf/compiler/all.T 6 additions, 3 deletionstestsuite/tests/perf/compiler/all.T
Loading
Please register or sign in to comment