Skip to content
Snippets Groups Projects
Commit ce616f49 authored by Simon Peyton Jones's avatar Simon Peyton Jones
Browse files

Fix infelicities in the Specialiser

On the way to #23109 (unary classes) I discovered some infelicities
(or maybe tiny bugs, I forget) in the type-class specialiser.

I also tripped over #25965, an outright bug in the rule matcher

Specifically:

* Refactor: I enhanced `wantCallsFor`, whih previously always said
`True`, to discard calls of class-ops, data constructors etc.  This is
a bit more efficient; and it means we don't need to worry about
filtering them out later.

* Fix: I tidied up some tricky logic that eliminated redundant
  specialisations.  It wasn't working correctly.  See the expanded
  Note [Specialisations already covered], and
  (MP3) in Note [Specialising polymorphic dictionaries].

  See also the new top-level `alreadyCovered`
  function, which now goes via `GHC.Core.Rules.ruleLhsIsMoreSpecific`

  I also added a useful Note [The (CI-KEY) invariant]

* Fix #25965: fixed a tricky bug in the `go_fam_fam` in
  `GHC.Core.Unify.uVarOrFam`, which allows matching to succeed
  without binding all type varibles.

  I enhanced Note [Apartness and type families] some more

* #25703. This ticket "just works" with -fpolymorphic-specialisation;
  but I was surprised that it worked! In this MR I added documentation
  to Note [Interesting dictionary arguments] to explain; and tests to
  ensure it stays fixed.
parent 7641a74a
No related branches found
No related tags found
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment