Re: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar"

#15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon made a commit (9fc40c733ba8822a04bd92883801b214dee099ca) addressing the issue in comment:24, but he accidentally tagged the wrong ticket number. Here is the commit: {{{ From 9fc40c733ba8822a04bd92883801b214dee099ca Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Mon, 25 Jun 2018 13:20:59 +0100 Subject: [PATCH] Refactor the kind-checking of tyvar binders The refactoring here is driven by the ghastly mess described in comment:24 of Trac #1520. The overall goal is to simplify the kind-checking of typev-variable binders, and in particular to narrow the use of the "in-scope tyvar binder" stuff, which is needed only for associated types: see the new Note [Kind-checking tyvar binders for associated types] in TcHsType. Now * The "in-scope tyvar binder" stuff is done only in - kcLHsQTyVars, which is used for the LHsQTyVars of a data/newtype, or type family declaration. - tcFamTyPats, which is used for associated family instances; it now calls tcImplicitQTKBndrs, which in turn usese newFlexiKindedQTyVar * tcExpicitTKBndrs (which is used only for function signatures, data con signatures, pattern synonym signatures, and expression type signatures) now does not go via the "in-scope tyvar binder" stuff at all. While I'm still not happy with all this code, the code is generally simpler, and I think this is a useful step forward. It does cure the problem too. (It's hard to trigger the problem in vanilla Haskell code, because the renamer would normally use different names for nested binders, so I can't offer a test.) --- compiler/hsSyn/HsDecls.hs | 43 +++++-- compiler/typecheck/TcHsType.hs | 258 +++++++++++++++++++++---------------- compiler/typecheck/TcTyClsDecls.hs | 3 +- 3 files changed, 178 insertions(+), 126 deletions(-) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15290#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler