summaryrefslogtreecommitdiff
path: root/rts/Hash.c
diff options
context:
space:
mode:
authorRyan Scott <ryan.gl.scott@gmail.com>2020-08-31 07:15:09 -0400
committerRyan Scott <ryan.gl.scott@gmail.com>2020-09-12 16:18:51 -0400
commit7590dfb6514d2f898908bec428334cff7d116326 (patch)
tree1ed494a401e2f84ac359ebaee7d36ed2c0c38b55 /rts/Hash.c
parent8440b5fa1397940f2f293935927e690b34110a73 (diff)
downloadhaskell-wip/wire-in-constraint-tuples.tar.gz
Wire in constraint tupleswip/wire-in-constraint-tuples
This wires in the definitions of the constraint tuple classes. The key changes are in: * `GHC.Builtin.Types`, where the `mk_ctuple` function is used to define constraint tuple type constructors, data constructors, and superclass selector functions, and * `GHC.Builtin.Uniques`. In addition to wiring in the `Unique`s for constraint tuple type and data constructors, we now must wire in the superclass selector functions. Luckily, this proves to be not that challenging. See the newly added comments. Historical note: constraint tuples used to be wired-in until about five years ago, when commit 130e93aab220bdf14d08028771f83df210da340b turned them into known-key names. This was done as part of a larger refactor to reduce the number of special cases for constraint tuples, but the commit message notes that the main reason that constraint tuples were made known-key (as opposed to boxed/unboxed tuples, which are wired in) is because it was awkward to wire in the superclass selectors. This commit solves the problem of wiring in superclass selectors. Fixes #18635. ------------------------- Metric Decrease: T10421 T12150 T12227 T12234 T12425 T13056 T13253-spj T18282 T18304 T5321FD T5321Fun T5837 T9961 Metric Decrease (test_env='x86_64-linux-deb9-unreg-hadrian'): T12707 Metric Decrease (test_env='x86_64-darwin'): T4029 -------------------------
Diffstat (limited to 'rts/Hash.c')
0 files changed, 0 insertions, 0 deletions