#12130: ghc: panic! (the 'impossible' happened): find_tycon Block [] -------------------------------------+------------------------------------- Reporter: jeiea | Owner: adamgundry Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: | DisambiguateRecordFields Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T12130 Blocked By: | Blocking: Related Tickets: #11228 | Differential Rev(s): Phab:D2321 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd/ghc" 2f8cd14/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd" Narrow the use of record wildcards slightly In reviewing the fix to Trac #12130 I found the wild-card fill-in code for ".." notation in record constructions hard to understand. It went to great contortions (including the find_tycon code) to allow data T = C { x, y :: Int } f x = C { .. } to expand to f x = C { x = x, y = y } where 'y' is an /imported function/! That seems way over the top for what record wildcards are supposed to do. So I have narrowed the record-wildcard expansion to include only /locally-bound/ variables; i.e. not top level, and certainly not imported. I don't think anyone is using record wildcards in this bizarre way, so I don't expect any fallout. Even if there is, you can easily initialise fields with eponymous but imported values by hand. An intermediate position would be to allow /local/ top-level definitions. But I doubt anyone is doing that either. Let's see if there's any fallout. It's a local change, easy to revert, so I've just gone ahead to save everyone's time. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12130#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler