November 2016 - ghc-tickets

[GHC] #12699: Suspicious treatment of renaming of field labels
by GHC 01 Mar '17

01 Mar '17

#12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- While working on my rework of interface file names (Phab:D2467) I noticed that there is some funniness in the treatment of renaming field selectors. Namely, `ifaceConDeclFields` are `IfaceTopBndr`s (and should therefore be renamed), renaming them causes `bkpreex06` to fail with the panic `find_lbl missing foo`. Looking at the environment reveals that there are selectors named `foo` in scope, but they were not renamed. I believe this is due to the implementation of `tcIfaceDataCons`, which typechecks the fields with `mapM (traverse lookupIfaceTop) (ifaceConDeclFields if_cons)`. In essence, this projects the field labels back to `OccName`s (in `ifaceConDeclFields`) and then looks each of these `OccName`s up in the name cache, thereby retrieving the un-renamed `Name`. This seems wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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] #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] #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] #12885: "too many iterations" causes constraint solving issue.
by GHC 25 Feb '17

25 Feb '17

#12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 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: -------------------------------------+------------------------------------- The following file compiled fine with ghc-7.10, but fails in ghc-8.0.2-rc1 (as well as ghc-8.0.1). This is a simplified version of a compilation issue with ghc-8 and https://github.com/tensorflow/haskell. It seems similar to #12175, but even though that was fixed in ghc-8.0.2-rc1, the below code still doesn't compile. {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module ConstraintTest where import Data.Int import Data.Word import GHC.Exts (Constraint) import Lens.Family2 ((.~), (&), Lens') import Lens.Family2.Unchecked (lens) class MyType a where instance MyType Int8 instance MyType Int16 instance MyType Int32 instance MyType Int64 instance MyType Word8 instance MyType Word16 instance MyType Word32 -- Require every element in the list to be an instance of 'MyType'. type family MyTypes (as :: [*]) :: Constraint where MyTypes '[] = () MyTypes (a ': as) = (MyType a, MyTypes as) data Foo = Foo { fooInt :: Int } class Attr a where attr :: Lens' Foo a instance Attr Int where attr = lens fooInt (\f n -> f { fooInt = n }) test :: MyTypes '[Int8,Int16,Int32,Int64,Word8,Word16,Word32] => Foo test = attr .~ (3 :: Int) $ Foo 0 }}} Compilation error: {{{ tensorflow/tests/ConstraintTest.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [W] hole{a282} :: b_a25A ~ Int (CNonCanonical)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Some ways to change the test to make the compilation succeed: - Pass "-fconstraint-solver-iterations=0" to ghc. - Shorten the type-level list in the constraint of `test`. - Replace `Lens.Family2` with `Lens.Micro` from the `microlens` package. I think this is because `Lens.Family2`'s version of (.~) is higher-order than `Lens.Micro`: https://hackage.haskell.org/package/lens-family-1.2.1/docs/Lens- Family2.html#v:.-126- https://hackage.haskell.org/package/microlens-0.4.7.0/docs/Lens- Micro.html#v:.-126- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS
by GHC 25 Feb '17

25 Feb '17

#12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an annoyance I discovered when working with the [https://github.com/rrnewton/haskell- lockfree/tree/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops atomic-primops] package on Windows. Here is a simplified test case: {{{#!hs module Main (main) where foreign import ccall unsafe "store_load_barrier" storeLoadBarrier :: IO () main :: IO () main = do putStrLn "1" storeLoadBarrier putStrLn "2" }}} Compiling and running this program works without issue. But when run as GHCi bytecode, it fails. I've reproduced this with GHC 8.0.1 and HEAD (but based on [https://github.com/rrnewton/haskell-lockfree/pull/38 this], the issue is likely much older than 8.0.1). {{{ $ runghc Bug.hs Bug.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: store_load_barrier 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 }}} To work around this issue, `atomic-primops` currently links against [https://github.com/rrnewton/haskell- lockfree/blob/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic- primops/cbits/RtsDup.c#L52-L69 a separate C file] that contains an exact duplicate of the `store_load_barrier` function from GHC's RTS when build on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM
by GHC 25 Feb '17

25 Feb '17

#12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The example is slimmed down unit test of Annotations-0.2.1 hackage package. If we try to compile Bug.hs with -O0 it compiles quickly. Trying it with -O1 makes GHC-8.0.1 takes a minute to finish. {{{#!hs -- Bug1.hs: {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} {- # OPTIONS_GHC -O1 #-} module Bug () where import Prelude (Eq) data ExprF rT = ExprF rT rT deriving Eq newtype Expr = Expr (Fix ExprF) deriving Eq newtype Fix fT = In (fT (Fix fT)) deriving instance Eq (f (Fix f)) => Eq (Fix f) }}} {{{ $ time ghc-8.0.1 -c -O0 Bug1.hs -fforce-recomp real 0m0.611s user 0m0.549s sys 0m0.053s $ time ghc-8.0.1 -c -O1 Bug1.hs -fforce-recomp real 1m2.199s user 1m1.676s sys 0m0.465s }}} 7.10.2 for comparison is very quick in both O0/O1: {{{ $ time ghc-7.10.2 -c -O0 Bug1.hs -fforce-recomp real 0m0.220s user 0m0.183s sys 0m0.036s $ time ghc-7.10.2 -c -O1 Bug1.hs -fforce-recomp real 0m0.237s user 0m0.213s sys 0m0.023s }}} The real ExprF datatype uses more constructors and instances: {{{ data ExprF rT = Add rT rT | Sub rT rT | Mul rT rT | Div rT rT | Num Int deriving (Eq, Show) }}} That requires a lot of time and space to finish (Bug2.hs in attach). I've stopped it after 5 minutes (took ~8GB RAM). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19