#13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aavogt): * Attachment "too_eager.hs" added. minimal test case coming from Data.HList.Dredge -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13371 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: niteria (added) Comment: I tried to figure out where in the 8.0.2 branch this regression was introduced. Unfortunately, I wasn't able to isolate an exact commit, because the range of commits in which it was introduced doesn't build. However, I know for sure it was introduced between: * cc02156b859159eff7d86043f67826c17f2bd170 (where the bug is not present): {{{ From cc02156b859159eff7d86043f67826c17f2bd170 Mon Sep 17 00:00:00 2001 From: Bartosz Nitka Date: Mon, 18 Apr 2016 07:32:03 -0700 Subject: [PATCH] Make benign non-determinism in pretty-printing more obvious This change takes us one step closer to being able to remove `varSetElemsWellScoped`. The end goal is to make every source of non-determinism obvious at the source level, so that when we achieve determinism it doesn't get broken accidentally. Test Plan: compile GHC Reviewers: simonmar, goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2123 GHC Trac Issues: #4012 (cherry picked from commit 0f96686b10fd36d479a54c71a6e1753193e85347) }}} * ae94a31e7f162b4a3ef6b6f837bd6006a98f639a (where the bug is present): {{{ From ae94a31e7f162b4a3ef6b6f837bd6006a98f639a Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Fri, 22 Apr 2016 10:47:14 +0100 Subject: [PATCH] Refactor free tyvars on LHS of rules A RULE can have unbound meta-tyvars on the LHS. Consider data T a = C foo :: T a -> Int foo C = 1 {-# RULES "myrule" foo C = 1 #-} After type checking the LHS becomes (foo alpha (C alpah)) and we do not want to zap the unbound meta-tyvar 'alpha' to Any, because that limits the applicability of the rule. Instead, we want to quantify over it! Previously there was a rather clunky implementation of this quantification, buried in the zonker in TcHsSyn (zonkTvCollecting). This patch refactors it so that the zonker just turns the meta-tyvar into a skolem, and the desugarer adds the quantification. See DsBinds Note [Free tyvars on rule LHS]. As it happened, the desugarer was already doing something similar for dictionaries. See DsBinds Note [Free dictionaries on rule LHS] No change in functionality, but less cruft. (cherry picked from commit 6ad2b42f866fa718855cc5c850e3549bc1428b3c) }}} I doubt that ae94a31e7f162b4a3ef6b6f837bd6006a98f639a was responsible, since it seems to only touch rewrite RULES. Furthermore, niteria authored all commits between cc02156b859159eff7d86043f67826c17f2bd170 and that point. Do you have a hunch what might be happening here, niteria? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13371#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * cc: goldfire (added) Comment: I think this has been broken since 6746549772c5cc0ac66c0fce562f297f4d4b80a2. Running before c9bcaf3165586ac214fa694e61c55eb45eb131ab with `-dunique- increment=-1` reproduces the problem. It appears that when we `growThetaTyVarsDSet` we add some kind variables to the nondependent type var set, but the vars inside depend on the newly added kind var. We then linearize without any regard for dependencies, because there shouldn't be any. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13371#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7e96526ac2ef5987ecb03217d3d616b6281c1441/ghc" 7e96526/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7e96526ac2ef5987ecb03217d3d616b6281c1441" Fix TcSimplify.decideQuantification for kind variables TcSimplify.decideQuantification was doing the Wrong Thing when "growing" the type variables to quantify over. We were trying to do this on a tyvar set where we'd split off the dependent type varaibles; and we just got it wrong. A kind variable wasn't being generalised properly, with confusing knock on consequences. All this led to Trac #13371 and Trac #13393. This commit tidies it all up: * The type TcDepVars is renamed as CandidateQTvs; and splitDepVarsOfType to candidateQTyVarsOfType * The code in TcSimplify.decideQuantification is simpler. It no longer does the tricky "grow" stuff over TcDepVars. Instead it use ordinary VarSets (thereby eliminating the nasty growThetaTyVarsDSet) and uses that to filter the result of candidateQTyVarsOfType. * I documented that candidateQTyVarsOfType returns the type variables in a good order in which to quantify, and rewrote it to use an accumulator pattern, so that we would predicatably get left-to-right ordering. In doing all this I also made UniqDFM behave a little more nicely: * When inserting an element that is there already, keep the old tag, while still overwriting with the new value. * This means that when doing udfmToList we get back elements in the order they were originally inserted, rather than in reverse order. It's not a big deal, but in a subsequent commit I use it to improve the order of type variables in inferred types. All this led to a lot of error message wibbles: - changing the order of quantified variables - changing the order in which instances are listed in GHCi - changing the tidying of variables in typechecker erors There's a submodule update for 'array' because one of its tests has an error-message change. I may not have associated all of them with the correct commit. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13371#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T13371 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #13393 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13371#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler