August 2018 - ghc-tickets

[GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440
by GHC 19 Oct '18

19 Oct '18

#15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package | Version: 8.4.3 system | Keywords: cabal, cpphs, | Operating System: MacOS X strange closure | Type of failure: Building GHC Architecture: x86 | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attempting to install Agda via Cabal fails. I've installed cpphs through Cabal and {{{~/Library/Haskell/bin}}} is in my path. {{{~/.cabal/config}}} is default, but in {{{/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings}}} I have changed only {{{("C compiler supports -no- pie","NO")}}} (from "YES") because that was giving me errors earlier. The log states: "Please report this as a GHC bug..." so here I am :] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'
by GHC 18 Oct '18

18 Oct '18

#15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ % cat Nopie.hs module Nopie where main :: IO () main = putStrLn "hi" % ghc -fforce-recomp -c -fhpc Nopie.hs clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] }}} This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output. Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11307: Regresssion: parsing type operators
by GHC 17 Oct '18

17 Oct '18

#11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- GHC 7.10.3 will parse (but not type-check) the following {{{#!hs {-# LANGUAGE TypeOperators #-} type family (r1 :++: r2); infixr 5 :++: type instance r :++: Nil = r type instance r1 :++: r2 :> a = (r1 :++: r2) :> a }}} Current master (c7830bdb14e0a85a78617314156d101155fdf7aa) fails with {{{#!hs /tmp/Foo.hs:5:15: error: Malformed head of type or class declaration: r1 :++: r2 :> a }}} @simonpj comment on ghc-devs mailing list > `| type instance r1 :++: r2 :> a = (r1 :++: r2) :> a` > > What do you expect this to mean? I suppose you could hope that GHC will > unravel the fixity of :++: and :>, to determine whether you are giving an > instance for :++: or for :>? > > That sounds reasonable, but it's not trivial. > > Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and > it looks like this: > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_tycon :: Located name > , tfe_pats :: pats > , tfe_rhs :: LHsType name } > }}} > > So we've already decided (in the parser) what the type-function name is. > But we can't do that in this case, because the parser doesn't understand > fixity. > > To deal with this we'd need to change to > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_lhs :: LHSType name > , tfe_rhs :: LHsType name } > }}} > > so that the LHS was just a type. Now the renamer can re-jiggle its > fixities in the usual way, and only in the type checker will we need to > decide exactly which type it's an instance of. Easy! > > This might be a good change to make! It's a bit like in ClsInstDecl, you'll > see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed > into which class it is. > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15278: Add -Werror=compat, enable it in the testsuite
by GHC 16 Oct '18

16 Oct '18

#15278: Add -Werror=compat, enable it in the testsuite -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- = Proposed change Add a flag `-Werror=compat` to GHC which would have the effect of `-Werror=x -Werror=y ...` where `x, y, ...` are warnings from `minusWcompatOpts`. Enable `-Wcompat -Werror=compat` in the testsuite. = Motivation 1. `-Werror=compat` would be a convenient shorthand to ensure forwards- compatibility of code. I can imagine Haskell libs enabling it on their CI. 2. Enabling `-Wcompat -Werror=compat` in the testsuite would allow us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards-compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates. The idea came up during my work on Phab:D4834 which defines a new warning and adds it to `-Wcompat`. Ryan Scott raised the following concern: > There are likely many tests in the testsuite that will now fail due to this change—I'm unclear if you're intending to fix them by explicitly quantifying their kind variables, or leaving the new error message as-is. My intention was to update the test cases, but it turned out that I couldn't even locate these test cases without `make EXTRA_HC_OPTS="-fwarn- implicit-kind-vars -Werror=implicit-kind-vars"`. And even if I updated the testsuite, nothing would prevent new test cases that are not forwards- compatible, because the warning isn't enabled by default (and without `-Werror=compat`, enabling `-Wcompat` would not cause test failures in all circumstances). = Implementation plan 1. Add new flags: `-Werror=compat`, `-Wno-error=compat`, `-Wwarn=compat`. 2. Document these flags in the User's Guide. 3. Enable `-Wcompat -Werror=compat` in the testsuite by default and fix all tests that break. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13600: surprising error message with bang pattern
by GHC 15 Oct '18

15 Oct '18

#13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the following code {{{ f3 :: [Int] -> IO Int f3 x = return (sum x) f4 :: [Int] -> IO Int f4 !x = return (sum x) }}} gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation
by GHC 15 Oct '18

15 Oct '18

#12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code (depends on singletons-2.2): {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators, KindSignatures, TypeInType, TypeFamilyDependencies, UndecidableInstances #-} module Bug where import Data.Kind (Type) import Data.Singletons.Prelude (Map, SndSym0) import GHC.TypeLits (Nat) data Payload = A | B newtype NewType a = NewType Int type NatList = [(Nat, Payload)] type StripNatList (natList :: NatList) = Map SndSym0 natList type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (StripNatList xs) }}} Why GHC is okay with injectivity annotation for `Family`: `r -> natList`? These two types: {{{#!hs type Foo = Family '[ '(0, 'A), '(1, 'B)] type Bar = Family '[ '(0, 'A), '(0, 'B)] }}} are obviously map to the same type: {{{#!hs *Bug Data.Singletons.Prelude> :kind! Foo Foo :: * = NewType ('A :$$$ '['B]) *Bug Data.Singletons.Prelude> :kind! Bar Bar :: * = NewType ('A :$$$ '['B]) }}} ---- If inline `StripNatList` inside `Family` definition: {{{#!hs type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (Map SndSym0 xs) }}} or change `StripNatList` definition to type family: {{{#!hs type family StripNatList (natList :: NatList) where StripNatList '[] = '[] StripNatList ('(n, x) ': xs) = x ': StripNatList xs }}} compilation expectedly fails with `Type family equation violates injectivity annotation.` ---- Moreover, if I remove `NewType` from `Family` and change result kind: {{{#!hs type family Family (natList :: NatList) = (r :: [Payload]) | r -> natList where Family xs = StripNatList xs }}} it fails with correct error regardless of `StripNatList` definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14341: Show instance for TypeReps is a bit broken
by GHC 15 Oct '18

15 Oct '18

#14341: Show instance for TypeReps is a bit broken -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4084 | Wiki Page: -------------------------------------+------------------------------------- There are two problems. 1. Showing typereps of tuples can produce unnecessary parentheses: {{{ Prelude K T> typeRep @(Int, Maybe Bool) (Int,(Maybe Bool)) }}} The fix is trivial. 2. Showing typereps of ticked (i.e., lifted) tuples and lists gives hard- to-read results, because it does not use the usual special syntax: {{{ Prelude K T> typeRep @'(Int, Maybe Bool) '(,) * * Int (Maybe Bool) Prelude K T> typeRep @'[1,2,3] ': Nat 1 (': Nat 2 (': Nat 3 ('[] Nat))) }}} Fixing the lifted tuple case is trivial. Fixing the lifted list case is slightly less trivial, but not hard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14341> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14088: Allow users to omit`forall`
by GHC 15 Oct '18

15 Oct '18

#14088: Allow users to omit`forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Just an idea I wanted to get out there, I don't think it causes parsing ambiguity {{{#!hs -- id :: forall a. a -> a id :: a. a -> a -- everywhere :: (forall b. Term b => b -> b) -> (forall a. Term a => a -> a) everywhere :: (b. Term b => b -> b) -> (a. Term a => a -> a) }}} I think it looks beautiful but clearly more difficult to Google or grep for. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0
by GHC 15 Oct '18

15 Oct '18

#15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux accelerate,memory,compile | Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: accelerate | Blocked By: 1.2.0 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Every time I try to run {{{ cabal install accelerate }}} the compiler take up nearly all 4GB of memory. Stracing it reveals that it seems to be spending nearly all of the time it runs checking a timer file descriptor, and occasionally checking its memory usage without actually doing anything about the problem. This makes installing accelerate nearly impossible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15481: TH fails to recover from reifyFixity with -fexternal-interpreter
by GHC 14 Oct '18

14 Oct '18

#15481: TH fails to recover from reifyFixity with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.4.3 Haskell | Keywords: RemoteGHCi | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally reported at https://github.com/glguy/th- abstraction/issues/53.) If you compile the following program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH main :: IO () main = putStrLn $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) }}} It will work fine without the use of `-fexternal-interpreter`. However, using `-fexternal-interpreter` will result in an error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fforce-recomp -fexternal-interpreter [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:19: error: • The exact Name ‘foo_a3MT’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the untyped splice: $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) | 7 | main = putStrLn $(recover (stringE "reifyFixity failed") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Bug.hs:7:19: error: • The exact Name ‘foo_a3MT’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the untyped splice: $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) | 7 | main = putStrLn $(recover (stringE "reifyFixity failed") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8