December 2015 - ghc-tickets

Re: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking
by GHC 03 Dec '15

03 Dec '15

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George Karachalias <george.karachalias@…>): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/595#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5724: Confusing warning message for incomplete patterns
by GHC 03 Dec '15

03 Dec '15

#5724: Confusing warning message for incomplete patterns -------------------------------------+--------------------------------- Reporter: AntoineLatter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by George Karachalias <george.karachalias@…>): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5724#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11156: Type-changing record update catch-all in sum type doesn't typecheck
by GHC 02 Dec '15

02 Dec '15

#11156: Type-changing record update catch-all in sum type doesn't typecheck -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apologies for the confusing title/summary, but that is about as succinct as I could be. Rather than try to describe this in english, here is the smallest example I could repro with. I want to write this: {{{ import Data.Char data R a = Foo { x :: a, y :: a } | Bar { x :: a } | Baz { x :: a } ordify :: R Char -> R Int ordify r@(Foo {}) = r { x = ord (x r), y = ord (y r) } ordify r = r { x = ord (x r) } }}} But that fails to typecheck: {{{ $ ghci Test.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Test.hs, interpreted ) Test.hs:10:21: Couldn't match type ‘Char’ with ‘Int’ Expected type: R Int Actual type: R Char In the expression: r In the expression: r {x = ord (x r)} Failed, modules loaded: none. }}} Instead, I have to resort to enumerating all the remaining constructors: {{{ import Data.Char data R a = Foo { x :: a, y :: a } | Bar { x :: a } | Baz { x :: a } ordify :: R Char -> R Int ordify r@(Foo {}) = r { x = ord (x r), y = ord (y r) } ordify (Bar x) = Bar (ord x) ordify (Baz x) = Baz (ord x) }}} The sum type has the property that every constructor has the field x, and some constructors have fields which are also parameterized over x's type 'a'. I would expect my first example, with the catch-all record-update to typecheck, but it doesn't. I suspect GHC thinks the catch-all case of ordify might be passed a Foo constructor, in which case the record update would be ill-typed, even though that is impossible due to the first case matching Foo explicitly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11077: ghc panic: ieName failed pattern match
by GHC 02 Dec '15

02 Dec '15

#11077: ghc panic: ieName failed pattern match -------------------------------------+------------------------------------- Reporter: woehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My custom prelude module is producing the following panic in ghc: {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): ieName failed pattern match! Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The module is as follows: {{{#!hs module Prelude ( module X , tshow ) where import BasePrelude as X import Data.Text as X (Text, pack, unpack) tshow :: Show a => a -> Text tshow = pack . show }}} In my cabal file I depend on base-noprelude and base-prelude and use the above as my custom Prelude module. The panic is triggered by ```tshow```. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5850: Greater customization of GHCi prompt
by GHC 02 Dec '15

02 Dec '15

#5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: jlengyel => * status: closed => new * resolution: fixed => Comment: Unfortunately the patch that was previously merged intermittently hung for me. I've reverted it in d00cdf237f28d72df74157bfdf30e623786b68c3 and may return to this eventually. This shouldn't stop others from having a look, of course! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5850#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Dec '15

02 Dec '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <bnitka@…>): In [changeset:"741f837d652fd00671614d52a6cb16fbc3758480/ghc" 741f837d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="741f837d652fd00671614d52a6cb16fbc3758480" Implement more deterministic operations and document them I will need them for the future determinism fixes. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari, austin, hvr, simonmar Reviewed By: simonpj, simonmar Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D1537 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5850: Greater customization of GHCi prompt
by GHC 02 Dec '15

02 Dec '15

#5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: jlengyel Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was closed (a bit unintentionally) with 72e362076e7ce823678797a162d0645e088cd594. Regardless, I think the patch is in pretty good shape. Unfortunately it is attributed to me, whereas it is largely jlengyel's work. Thanks jlengyel and sorry about the lack of credit! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5850#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Dec '15

02 Dec '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <bnitka@…>): In [changeset:"218fdf92370021b900af1e78323764cceb7ac609/ghc" 218fdf9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="218fdf92370021b900af1e78323764cceb7ac609" Make the order of fixities in the iface file deterministic This normalizes the order of written fixities by sorting by `OccName` making it independent of `Unique` order. Test Plan: I've added a new testcase Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1557 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8098: Faulty Word64 arithmetic if optimized
by GHC 02 Dec '15

02 Dec '15

#8098: Faulty Word64 arithmetic if optimized ----------------------------+--------------------------------- Reporter: achp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The following program produces different results depending on optimization: Checked.hs: {{{ module Checked ((.-.)) where (.-.) :: (Bounded a, Integral a) => a -> a -> Maybe a x .-. y | x >= 0 && y < 0 = if z > x then Just z else Nothing | x >= 0 = if z <= x then Just z else Nothing | x < 0 && y > 0 = if z < x then Just z else Nothing | otherwise = Just z where z = x - y }}} Main.hs: {{{ module Main (main) where import Data.Maybe import Data.Word import Numeric import Checked main :: IO () main = print $ showHex (fromJust ((0xFFFFFFFF00000000 :: Word64) .-. 0x00000000FFFFFFFF)) "" }}} {{{ D:\dev\haskell\ch1>ghc --make Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffffffe00000001" D:\dev\haskell\ch1>del *.hi *.o *.exe D:\dev\haskell\ch1>ghc --make -O2 Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffe00000001" D:\dev\haskell\ch1> }}} The bug disappears if definition and usage of (.-.) are in the same module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Dec '15

02 Dec '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by niteria): @nomeata asked me to post an update, so here it goes. > What remains to be done, are the remaining problems solved (and just need doing)? So far I've only seen a recurring theme of non-deterministic uniques affecting the order of constructs in the code, like abstracted variables in a lambda. I believe the other problems have been solved before I started to work on this. This core of the problem is the `Ord` instance for `Unique`. It's used for: unique maps, computing SCCs, computing free variables, normalizing by sorting and type comparison. There are many instances of that, I'm sure I haven't discovered all of them yet, but conceptually the problem is rather simple and it's just a matter of putting the work. There's progress here, right now (I have some local patches) all 60 of the packages that I picked from stackage and still build with GHC HEAD rebuild deterministically. What I mean by that is that if you remove just the .o files, leaving existing .hi files, and start the build again you end up with the same result. I've recently shifted my focus from external packages, to GHC's tests since they offer nice small pieces of code. Here my method is a bit different, I run the tests with unique allocation reversed and compare the interface files. I've recently gone from 156 differing .hi files down to 26. All of these metrics are flawed in their own way and can fluctuate, so take them with a grain of salt. > Are there issues without a known solution so far? * Performance - so far I've spent a lot of time ensuring the performance is within the same ranges as before, forcing me to improve the free variable computation for example. In principle I could replace all the unique maps with deterministic unique maps and get a big chunk of non- determinism eliminated. The problem is that deterministic unique maps have a slower union operation and have to have extra memory to keep order. I've tried that and the cost was about 10% slower compilation times on `text` and `aeson`. So a lot of work is in just not creating regressions. * Ensuring that it stays fixed - so far this relies on tests which might be brittle + comments on places that I had to fix. It's a bit unsatisfying, I'd prefer a solution enforced by the compiler, like `Unique` not having an `Ord` instance. > The focus is now on reproducible interface files, what would it take to have reproducible binaries? I haven't looked much into that, but my gut feeling is that it's exactly the same problem, but you need to care about the passes after the core as well. I suspect you can get determinism today, if you don't do incremental builds and your build system builds single threaded. The external factor that affects the allocation of uniques is presence/absence of interface files. > Are there areas of work where you could need some extra help? So far my bottleneck has been making my patches mergeable in the sense of clean code and performance. Since the fixes stack on top of each other, because many files are a manifestation of more than one bug I think the easiest way to collaborate would be if I shared my unfinished patches and someone else ensured it's still performant enough and well documented. I've recently created #11148, which I believe is a bit more than a determinism bug, I've tried to look into it, but it was over my head, so that might be a more exciting way to pitch in. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0