November 2016 - ghc-tickets

[GHC] #12816: Link error with GOLD linker
by GHC 12 Nov '16

12 Nov '16

#12816: Link error with GOLD linker -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Linking) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 1. I think we should add "pthread" to the list of extra-libs in "rts/package.conf.in" for the threaded RTS on UNIX-like host OSes. 2. we should include MachDeps.h in "rts/package.conf.in" Current master branch (2e8463b232054b788b73e6551947a9434aa76009) build is broken on my system[0]. When ghc-stage1 tries to produce ghc-stage2, I get: {{{ /home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_create' /home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_detach }}} (logs: http://pastebin.com/EbqEx6Gg ) I have tracked down the regression to the following recent commit: a977c96537bb7077c6445f02db98636b150e6e14 If I revert this commit, it builds. However I think this commit has only revealed the bug: if I add "pthread" to the list of extra-libs in "rts/package.conf.in", it builds too. We already add it on freebsd and openbsd but not on Linux. I think I have finally found out why other devs on #ghc haven't noticed this bug: my system uses the GOLD linker (because of #12748), but if I switch back to the BFD linker, it builds without error. While investigating this bug, I have noticed that linker flags for 64-bit atomic ops introduced by https://git.haskell.org/ghc.git/commitdiff/c06e3f46d24ef69f3a3d794f5f604cb8… aren't set while they should: WORD_SIZE_IN_BITS isn't defined because we don't include MachDeps.h [0] x86-64, ArchLinux (Linux 4.8.6), GNU gold (GNU Binutils 2.27) 1.12, gcc (GCC) 6.2.1 20160830 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12812: Debugging functions should throw warnings
by GHC 12 Nov '16

12 Nov '16

#12812: Debugging functions should throw warnings -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: | Version: 8.0.1 libraries/base | 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 function Debug.Trace.trace is useful for debugging, however, we don't want this function to be present in production code. An excerpt from Debug.Trace explains why: {{{ The 'trace' function should /only/ be used for debugging, or for monitoring execution. The function is not referentially transparent: its type indicates that it is a pure function but it has the side effect of outputting the trace message. }}} It would be useful if the compiler threw warnings when such functions are used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12829: Multiline input (‘:set +m’) terminated by trailing whitespace
by GHC 12 Nov '16

12 Nov '16

#12829: Multiline input (‘:set +m’) terminated by trailing whitespace -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set +m Prelude> let Prelude| a :: Int Prelude| a = 5 Prelude| Prelude> }}} works fine with [https://downloads.haskell.org/~ghc/master/users- guide/ghci.html#multiline-input multiline input], but if you add one trailing space it immediately terminates the input {{{ Prelude> let Prelude| a :: Int␣ <interactive>:11:1: error: The type signature for ‘a’ lacks an accompanying binding }}} I don't know if this is the desired behavior but this means I can't copy/paste code into GHCi that has a trailing whitespace. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12829> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 12 Nov '16

12 Nov '16

#7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => Comment: This isn't an immediate priority (although tjakway has expressed interest in picking it up). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12021: Type variable escapes its scope
by GHC 12 Nov '16

12 Nov '16

#12021: Type variable escapes its scope -------------------------------------+------------------------------------- Reporter: ttuegel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, I believe a type variable is incorrectly escaping its scope. The example produces the error: {{{ Bug.hs:20:20: error: • Expected kind ‘Cat k’, but ‘(:-)’ has kind ‘Constraint -> Constraint -> *’ • In the first argument of ‘Iso’, namely ‘(:-)’ In the type signature: functor :: forall a b. Iso (:-) (:-) (Ob (Dom f) a) (Ob (Dom f) b) (Ob (Cod f) (f a)) (Ob (Cod f) (f b)) In the class declaration for ‘Functor’ }}} If the definition of `Iso` is changed from {{{#!hs type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. (Cod p ~ Nat d (->)) => p a b -> p s t }}} to {{{#!hs type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. p a b -> p s t }}} then this error does not occur. (The example still will not compile because I have omitted almost the entire implementation, but it should not fail here.) I am not certain what is really happening here, but it seems to me that when the RHS of `Iso` is constrained, then the type variable `k` introduced on the LHS of `Iso` is being unified incorrectly with the type variable `k` introduced in the definition of the `Functor` class. When the constraint is removed, GHC seems to recognize (correctly!) that the type variables are distinct. (This bug actually occurs with GHC 8.0.1-rc4, but the "Version" menu doesn't give me that option.) {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import GHC.Base ( Constraint, Type ) type Cat k = k -> k -> Type class Category (p :: Cat k) where type Ob p :: k -> Constraint class (Category (Dom f), Category (Cod f)) => Functor (f :: j -> k) where type Dom f :: Cat j type Cod f :: Cat k functor :: forall a b. Iso (:-) (:-) (Ob (Dom f) a) (Ob (Dom f) b) (Ob (Cod f) (f a)) (Ob (Cod f) (f b)) class (Functor f , Dom f ~ p, Cod f ~ q) => Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) | f -> p q instance (Functor f , Dom f ~ p, Cod f ~ q) => Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) data Nat (p :: Cat j) (q :: Cat k) (f :: j -> k) (g :: j -> k) type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. (Cod p ~ Nat d (->)) => p a b -> p s t data (p :: Constraint) :- (q :: Constraint) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12797: Default Rules stop working when providing some constraints
by GHC 12 Nov '16

12 Nov '16

#12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I've just found a very strange behavior. Let's consider following program: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE OverloadedStrings #-} module Main where import Prelude import Control.Monad.IO.Class type family FuncArg m where FuncArg ((->) t) = 'Just t FuncArg m = 'Nothing test1 :: (MonadIO m) => m () test1 = do liftIO $ print "tst" test2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () test2 = do liftIO $ print "tst" main :: IO () main = return () }}} The function `tst1` compiles fine, while `tst2` fails: {{{ exe/Main.hs:21:14: error: • Could not deduce (Show a0) arising from a use of ‘print’ from the context: (MonadIO m, FuncArg m ~ 'Nothing) bound by the type signature for: tst2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () at exe/Main.hs:19:1-49 The type variable ‘a0’ is ambiguous These potential instances exist: instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ ...plus 22 others ...plus 7 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the second argument of ‘($)’, namely ‘print "tst"’ In a stmt of a 'do' block: liftIO $ print "tst" In the expression: do { liftIO $ print "tst" } exe/Main.hs:21:20: error: • Could not deduce (Data.String.IsString a0) arising from the literal ‘"tst"’ from the context: (MonadIO m, FuncArg m ~ 'Nothing) bound by the type signature for: tst2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () at exe/Main.hs:19:1-49 The type variable ‘a0’ is ambiguous These potential instances exist: instance a ~ Char => Data.String.IsString [a] -- Defined in ‘Data.String’ ...plus one instance involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘print’, namely ‘"tst"’ In the second argument of ‘($)’, namely ‘print "tst"’ In a stmt of a 'do' block: liftIO $ print "tst" }}} Giving explicit types to String literals fixes the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _"
by GHC 12 Nov '16

12 Nov '16

#12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | 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: -------------------------------------+------------------------------------- I got the following error compiling simple source file Bad.hs. The bug is likely related to TH as the crash vanishes without the TH line. $ stack ghc -- -c Bad.hs Run from outside a project, using implicit global project config Using resolver: lts-7.5 from implicit global project's config file: /home/jchia/.stack/global-project/stack.yaml ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): compiler/typecheck/TcExpr.hs:798:15-35: Irrefutable pattern failed for pattern sel_id : _ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12771: GHCi incorrectly favors static libraries over import libraries
by GHC 12 Nov '16

12 Nov '16

#12771: GHCi incorrectly favors static libraries over import libraries ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- Given a static library and an import library in the same folder. e.g. {{{ libfoo.a libfoo.dll.a }}} running `ghci -lfoo` we should prefer the import library `libfoo.dll.a` over `libfoo.a` because we prefer having to just load the DLL. and not having to do any linking. This also more closely emulated the behaviour of LD, which has a search order of {{{ libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12732: GHC bug
by GHC 12 Nov '16

12 Nov '16

#12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- A frog told me about this {{{#!hs (a ... b) xs | a == x , (l, _:r) <- break (== x) xs = l ++ [x] }}} {{{ baldur@Loki:~$ ghci -fobject-code -fdefer-typed-holes -ignore-dot-ghci /tmp/tnVL.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tnVL.hs, /tmp/tnVL.o ) /tmp/tnVL.hs:2:10: warning: [-Wtyped-holes] Variable not in scope: x /tmp/tnVL.hs:3:27: warning: [-Wtyped-holes] Variable not in scope: x /tmp/tnVL.hs:4:11: warning: [-Wtyped-holes] Variable not in scope: x ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): StgCmmEnv: variable not found $dEq_a26w local binds for: $trModule $trModule1_r29y $trModule2_r2a9 x_r2aa x1_r2ab x2_r2ac a2_s2ah b_s2ai xs_s2aj fail_s2ak Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} I managed to find a more minimal example {{{#!hs u a | a == x = undefined }}} doesn't trigger error in GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12774: bkpcabal02 test fails on OS X
by GHC 12 Nov '16

12 Nov '16

#12774: bkpcabal02 test fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- While testing on Darwin today I noticed that the `bkpcabal02` test seems to fail. {{{ =====> bkpcabal02(normal) 1 of 1 [0, 0, 0] cd "./backpack/cabal/bkpcabal02/bkpcabal02.run" && $MAKE -s --no-print- directory bkpcabal02 CLEANUP=1 Wrong exit code (expected 0 , actual 2 ) Stdout: Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for bkpcabal01-0.1.0.0... Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for bkpcabal01-0.1.0.0... Stderr: make[2]: *** [bkpcabal02] Error 1 *** unexpected failure for bkpcabal02(normal) }}} Or more verbosely, {{{ $ make bkpcabal02 rm -f -r tmp.d inst dist Setup /Applications/Xcode-7.2/Xcode.app/Contents/Developer/usr/bin/make -s --no- print-directory clean '/Users/bgamari/ghc/inplace/test spaces/ghc-pkg' init tmp.d '/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' -v0 --make Setup cp p/H.hsig.in1 p/H.hsig # typecheck everything ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc='/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' --ghc-options ='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -dno-debug-output' --package- db=tmp.d --prefix='/Users/bgamari/ghc/testsuite/tests/backpack/cabal/bkpcabal02/inst' ./Setup -v0 build ./Setup -v0 -v1 build Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for bkpcabal01-0.1.0.0... Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for bkpcabal01-0.1.0.0... cp p/H.hsig.in2 p/H.hsig ! ./Setup -v0 build make: *** [bkpcabal02] Error 1 }}} It looks like the `./Setup build` command is finishing successfully where it is expected to fail. I generally don't mind debugging this sort of issue but in this case it's quite unclear why this is expected to fail. Edward, can you add some comments to the `all.T` for this testcase (and perhaps the other Backpack tests too if neceessary) explaining what this test is supposed to be testing for and why `Setup build` should fail? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4