January 2017 - ghc-tickets

[GHC] #8779: Exhaustiveness checks for pattern synonyms
by GHC 28 Feb '17

28 Feb '17

#8779: Exhaustiveness checks for pattern synonyms -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Pattern synonyms are great, as they decouple interface from implementation. Especially if #8581 is also implemented, it should be possible to change a type completely while retaining the existing interface. Exciting! Another missing piece is exhaustiveness checks. Given this pattern {{{ initLast [] = Nothing initLast xs = Just (init xs, last xs) pattern xs ::: x <- (initLast -> Just (xs,x)) }}} we want the compiler to tell the programmer that {{{ f [] = ... f (xs ::: x) = ... }}} is complete, while {{{ g (xs ::: x) = ... }}} is not. With view pattern directly, this is impossible. But the programmer did not write view patterns! So here is what I think might work well, inspired by the new `MINIMAL` pragma: We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). The syntax is essentially the same as for `MINIMAL`, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case. {{{ {-# COMPLETE_PATTERNS [] && (:::) #-} }}} Multiple pragmas are obviously combined with `||`, and there is an implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data constructors. When checking for exhaustiveness, this would be done before unfolding view patterns, and for `g` above we get a warning that `[]` is not matched. Again, the implementation is very much analogous to `MINIMAL`. Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` pragmas. I think that is ok (like with `MINIMAL`), and generally an improvement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 58

[GHC] #13070: time after evaluation
by GHC 27 Feb '17

27 Feb '17

#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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: -------------------------------------+------------------------------------- the {{{:set +s}}} gives the time after each evaluation.This time may have a difference of 68% in same calculation.It should not change after each evaluation of computation. Can we have a fixed and real time? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12459: UnboxedTuple makes overloaded labels fail to parse
by GHC 26 Feb '17

26 Feb '17

#12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: orf | 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: -------------------------------------+------------------------------------- [https://gist.githubusercontent.com/PkmX/bfb2c5af4317c96282795f8c588fda1c/ra… This] works (removing spaces) {{{#!hs -- user = ( #login := "themoritz", #id := 3522732 ) user :: User user = (#login := "themoritz", #id := 3522732) }}} but it doesn't when `UnboxedTuples` are enabled: {{{#!hs -- tWKw.hs:63:46: error: parse error on input ‘)’ user = (#login := "themoritz", #id := 3522732) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12223: Get rid of extra_files.py
by GHC 26 Feb '17

26 Feb '17

#12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 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: -------------------------------------+------------------------------------- Hello thomie! When you refactored the test suite you added `testsuite/driver/extra_files.py` to record what extra files need to get copied. In it, there is a comment "Maybe move this information to .T files at some point." This ticket is to remind you so you don't forget. This file is *extremely* un-discoverable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13171: panic on negative literal in case on Word
by GHC 26 Feb '17

26 Feb '17

#13171: panic on negative literal in case on Word -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- {{{#!hs module Case where f :: Word -> Word f n = case n of -1 -> 2 _ -> 3 }}} {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170119 for x86_64-unknown-linux): ASSERT failed! -1 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1182:22 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/Literal.hs:223:75 in ghc:Literal Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1180:5 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/Literal.hs:223:75 in ghc:Literal Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Doesn't happen in 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10246: Literal Pattern match loses order
by GHC 26 Feb '17

26 Feb '17

#10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I found this long-standing bug while investigating #10245: Consider this code: {{{ f1 :: Int -> String f1 n = case n of 0 -> "bar" 0x10000000000000000 -> "foo" _ -> "c" {-# NOINLINE f1 #-} g1 :: Int -> String g1 n = if n == 0 then "bar" else if n == 0x10000000000000000 then "foo" else "c" {-# NOINLINE g1 #-} f2 :: Int -> String f2 n = case n of 0x10000000000000000 -> "foo" 0 -> "bar" _ -> "c" {-# NOINLINE f2 #-} g2 :: Int -> String g2 n = if n == 0x10000000000000000 then "foo" else if n == 0 then "bar" else "c" {-# NOINLINE g2 #-} main = do let i = read "0" :: Int print (f1 i) print (g1 i) print (f2 i) print (g2 i) }}} According to the report, `f1` should behave like `g1` and `f2` should behave like `g2`. But that is not the case: I get {{{ "foo" "bar" "foo" "foo" }}} The reason is that the branches are sorted, to create fancy code for it, but this does not take into account that `0x10000000000000000 = 0`, at least for `Int`. This bug is present also in 7.8.4, and not (directly) related to my CmmSwitch code: It can also be observed with interpreted code, so the fix must happen earlier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10246> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code
by GHC 26 Feb '17

26 Feb '17

#9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code outputs "A". {{{#!hs import Data.Word x :: Word x = 10 y :: Word y = 11 test = case x - y of -1 -> "A" _ -> "B" main = putStrLn $ show test }}} However, adding a new case that isn't matched causes the output to change: {{{#!hs import Data.Word x :: Word x = 10 y :: Word y = 11 test = case x - y of 5 -> "C" -1 -> "A" _ -> "B" main = putStrLn $ show test }}} With the extra '5 -> "C"' line in the case, the output is "B". It gets weirder - interpreted code actually continues to match the -1 case. With the second example in a file 'T.hs', here is a GHCi session: {{{ Prelude Main> :l *T.hs [1 of 1] Compiling Main ( T.hs, interpreted ) Ok, modules loaded: Main. *Main> main "A" *Main> :l T.hs Ok, modules loaded: Main. Prelude Main> main "B" Prelude Main> }}} These examples suggest to me at least 3 improvements: * Issue a warning when a negative number is used in a case statement in unsigned context * Interpreted code should give the same result as compiled code * Adding a case that isn't matched shouldn't change which other patterns get matched -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886
by GHC 26 Feb '17

26 Feb '17

#10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- {{{#!hs import System.Directory import System.IO main = do (p, _) <- openTempFile "/tmp" "" print p removeFile p }}} {{{#!console $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" }}} This “random” number is the concatenation of the first two numbers 1804289383, 846930886 returned by glibc’s `rand()` when not seeded (or seeded with 1). This is not immediately a library security bug, I think: the file is created with `O_EXCL`, and if it already exists, `openTempFile` will move onto the next value 16816927771714636915, and so on. However, the predictable filenames make a potential application security bug that much more likely. (For your amusement, [https://www.google.com/search?q=1804289383846930886 Google 1804289383846930886].) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13113: Runtime linker errors with CSFML on Windows
by GHC 26 Feb '17

26 Feb '17

#13113: Runtime linker errors with CSFML on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Another day, another runtime linker bug on Windows. This time, it's from the CSFML library (written in C++). I observed this when trying to load the [http://hackage.haskell.org/package/SFML SFML] Haskell library in GHCi. To install CSFML in MSYS2: {{{ pacman -S mingw-w64-x86_64-csfml }}} Here's the Haskell code I'm using: {{{#!hs module Main (main) where import Foreign.Ptr newtype CircleShape = CircleShape (Ptr CircleShape) deriving Show foreign import ccall unsafe "sfCircleShape_create" sfCircleShape_create :: IO CircleShape foreign import ccall unsafe "sfCircleShape_copy" sfCircleShape_copy :: CircleShape -> IO CircleShape main :: IO () main = do putStrLn "----------------------" cs1 <- sfCircleShape_create print cs1 cs2 <- sfCircleShape_copy cs1 print cs2 putStrLn "----------------------" }}} Compiling it with `ghc -lcsfml-graphics SFML.hs` on GHC 8.0.2 and HEAD seems to work fine. But if you run it in GHCi, it breaks. With GHCi 8.0.2: {{{ $ ghci -lcsfml-graphics SFML.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc.exe: addDLL: csfml-graphics-2.dll (Win32 error 127): The specified procedure could not be found. ghc.exe: Could not load `csfml-graphics-2.dll'. Reason: addDLL: could not load DLL Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf [1 of 1] Compiling Main ( SFML.hs, interpreted ) Ok, modules loaded: Main. > main ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: sfCircleShape_create This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} With GHC HEAD: {{{ $ ..\..\..\Software\ghc\inplace\bin\ghci -lcsfml-graphics SFML.hs GHCi, version 8.1.20170108: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: addDLL: csfml-graphics-2.dll (Win32 error 127): The specified procedure could not be found. ghc-stage2.exe: Could not load `csfml-graphics-2.dll'. Reason: addDLL: could not load DLL Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf Ok, modules loaded: Main (SFML.o). > main ghc-stage2.exe: C:\Users\RyanGlScott\Documents\Hacking\Haskell\SFML.o: unknown symbol `sfCircleShape_create' }}} I also get the same error with Phab:D2941 (#13082) applied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13189: Implement same specification as GHC spec file for mingw32
by GHC 26 Feb '17

26 Feb '17

#13189: Implement same specification as GHC spec file for mingw32 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13093 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the `GCC` driver envokes the pipeline a `SPEC` is used to determine how to configure the compiler and which libraries to pass along. For Windows/mingw, this specfile is https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h This has a lot of interesting things that we need to emulate in order to be able to link as many things out of the box as GCC. In particular this is why you never need to specify `-lgcc_s` when compiling, but you do when using `GHCi`. Or specifying what `-mwindows` links in, that when `-lstdc++` is used what else to link in. Which base DLLs GCC will always link with when building an exe. And how to link `libgcc`, either static or dynamically. Currently we only support static linking of `libgcc` (which maybe we should change? or at least make user changeable). The current partial implementation works by adding hooks into the RTS. A better implementation is adding it all outside the RTS in the `DriverPipeline` tied directly to the commandline options. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2