October 2018 - ghc-tickets

[GHC] #15552: Infinite loop/panic with an existential type.
by GHC 05 Oct '18

05 Oct '18

#15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14723 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The symptoms of this bug are quite similar to #14723, but I don't know if the cause is exactly the same, ergo a new report. To reproduce: 1. Make `T.hs` {{{#!hs {-# LANGUAGE DataKinds, ExistentialQuantification, GADTs, PolyKinds, TypeOperators #-} module T where import Data.Kind data Elem :: k -> [k] -> Type where Here :: Elem x (x : xs) There :: Elem x xs -> Elem x (y : xs) data EntryOfVal (v :: Type) (kvs :: [Type]) = forall (k :: Type). EntryOfVal (Elem (k, v) kvs) }}} 2. Compile it with `ghc T.hs -ddump-tc-trace` {{{ # etc. checkExpectedKind * TYPE t_aXd[tau:1] <*>_N kcLHsQTyVars: not-cusk EntryOfVal [] [(k_aW0 :: Type)] [] [k_aW0[sk:1]] *ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): kcConDecl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} 3. Append the following to `T.hs` (not minimized, sorry) {{{#!hs type family EntryOfValKey (eov :: EntryOfVal v kvs) :: Type where EntryOfValKey ('EntryOfVal (_ :: Elem (k, v) kvs)) = k type family GetEntryOfVal (eov :: EntryOfVal v kvs) :: Elem (EntryOfValKey eov, v) kvs where GetEntryOfVal ('EntryOfVal e) = e type family FirstEntryOfVal (v :: Type) (kvs :: [Type]) :: EntryOfVal v kvs where FirstEntryOfVal v ((k, v) : _) = 'EntryOfVal Here FirstEntryOfVal v (_ : kvs) = 'EntryOfVal (There (GetEntryOfVal (FirstEntryOfVal v kvs))) }}} 4. Compile with a plain `ghc T.hs` 1. Wait until bored, then knock the compiler out of its infinite loop by killing it. 5. Compile again with `ghc T.hs -ddump-tc-trace` {{{ # etc. checkExpectedKind * TYPE t_aYg[tau:1] <*>_N kcLHsQTyVars: not-cuskghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): kcConDecl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Found while trying to answer [https://stackoverflow.com/q/51944931/5684257 this SO question]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13753: Improve GHC's ghc package environment lookup logic
by GHC 05 Oct '18

05 Oct '18

#13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.2.2 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: -------------------------------------+------------------------------------- Documentation for package enviroments which describes the current lookup logic: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.ht… #package-environments There's two things I'd like to improve: 1. Define a special magic "null" environment, which instructs GHC to ignore any package environment files. To this end, I propose to use the name `-` (i.e. a single dash), as that is more portable than using the empty string for environment variables. In other words: * `-package-env -` or * `GHC_ENVIRONMENT=-` (unless a `-package-env` flag which has higher priority overrides it) would prevent GHC from interpreting any package environment files. 2. Provide a way to disambiguate environment names (i.e. those that are looked up in `$HOME/.ghc/arch-os-version/environments/name`) and environment files arguments. Currently, if you say `GHC_ENVIRONMENT=test` then a local file `test` would shadow the environment named `test` which would result in rather confusing errors. Instead I suggest to have package-env identifiers be interpreted as "names" by default, and only if they look like relative or absolute paths (i.e. `./foobar` or `/home/foo/...`) be interpreted as file locations (relative to $CWD). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15436: Compile-time panic, Prelude.!!: negative index
by GHC 05 Oct '18

05 Oct '18

#15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a reproduction case: **ghc-repro.cabal** {{{ name: ghc-repro version: 0.0.0 build-type: Simple cabal-version: >= 1.10 library exposed-modules: Lib other-modules: Paths_ghc_repro hs-source-dirs: src build-depends: base default-language: Haskell2010 }}} **src/Lib.hs** {{{#!hs {-# OPTIONS_GHC -v4 #-} module Lib where import GHC.Enum -- | At this many elements, it panics. One fewer, it works data USState = AL | AK | AZ | AR | CA | CO | CT | DE | FL -- | GA -- | HI | ID | IL | IN | IA | KS | KY | LA | ME | MD -- | MA | MI | MN | MS | MO | MT | NE | NV | NH | NJ -- | NM | NY | NC | ND | OH | OK | OR | PA | RI | SC -- | SD | TN | TX | UT | VT | VA | WA | WV | WI | WY -- | DC | PR | VI | AS | GU | MP | AA | AE | AP deriving (Eq, Show, Ord, Bounded, Read, Enum) data USStateOrIntl = International | US USState instance Enum USStateOrIntl where fromEnum International = 0 fromEnum (US s) = 1 + fromEnum s enumFrom = boundedEnumFrom enumFromThen = boundedEnumFromThen toEnum 0 = International toEnum i = US . toEnum $ i - 1 instance Bounded USStateOrIntl where minBound = International maxBound = US maxBound }}} **Results**: {{{ ghc-repro-0.0.0: build (lib) Preprocessing library for ghc-repro-0.0.0.. Building library for ghc-repro-0.0.0.. Running phase HsPp HsSrcFile compile: input file src/Lib.hs *** Checking old interface for ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib (use -ddump-hi-diffs for more details): [1 of 2] Compiling Lib ( src/Lib.hs, .stack- work/dist/x86_64-linux/Cabal-2.2.0.1/build/Lib.o ) *** Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: !!! Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 8.31 milliseconds, allocated 17.533 megabytes *** Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: !!! Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 354.49 milliseconds, allocated 312.556 megabytes *** Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Desugar (after optimization) = {terms: 752, types: 352, coercions: 33, joins: 1/4} !!! Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 142.79 milliseconds, allocated 226.278 megabytes *** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Simplifier iteration=1 = {terms: 1,222, types: 790, coercions: 143, joins: 1/3} Result size of Simplifier iteration=2 = {terms: 1,219, types: 788, coercions: 126, joins: 0/1} Result size of Simplifier = {terms: 1,217, types: 786, coercions: 123, joins: 0/1} !!! Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 374.08 milliseconds, allocated 587.256 megabytes *** Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Specialise = {terms: 1,217, types: 786, coercions: 123, joins: 0/1} !!! Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 154.05 milliseconds, allocated 235.323 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [ghc- repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 1,551, types: 1,410, coercions: 123, joins: 0/0} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [ghc- repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 6.24 milliseconds, allocated 5.556 megabytes *** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Simplifier iteration=1 = {terms: 1,667, types: 1,082, coercions: 123, joins: 7/19} ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): Prelude.!!: negative index Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The above output was produced through my normal tooling, so {{{ stack build --resolver lts-12.2 --pedantic }}} To rule out stack, I was also able to reproduce the panic with plain cabal using this **Dockerfile**: {{{ FROM haskell:8.4.3 RUN mkdir /src WORKDIR /src COPY ghc-repro.cabal /src/ghc-repo.cabal COPY src/Lib.hs /src/src/Lib.hs RUN cabal build }}} {{{ docker build --tag ghc-repro . }}} It still panics, but the output is different and much larger so I'll leave it here: https://8n1.org/13499/5c92 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15260: Xmobar crashes with segmentation fault
by GHC 05 Oct '18

05 Oct '18

#15260: Xmobar crashes with segmentation fault --------------------------------------+---------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- OS: Arch Kernel version: 4.16.13-2-ARCH Xmobar version: 0.26 ghc version: 8.4.3 Xmobar crashes after some time (1 sec or 1 day - very different each time). And, as I see, reasons are different to: 1: {{{ voronwe@sul ~> xmobar Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha xmobar: internal error: evacuate: strange closure type 4689 (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug fish: 'xmobar' terminated by signal SIGABRT (Abort) }}} 2: {{{ voronwe@sul ~> xmobar Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha fish: 'xmobar' terminated by signal SIGSEGV (Address boundary error) }}} See my issue on xmobar github for details: https://github.com/jaor/xmobar/issues/354 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15709: GHC panic using TypeInType with minimal source code
by GHC 05 Oct '18

05 Oct '18

#15709: GHC panic using TypeInType with minimal source code -------------------------------------+------------------------------------- Reporter: jnape | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: TypeInType | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following source code causes GHC 8.4.3 on 64bit Linux to panic: {{{#!haskell {-# LANGUAGE TypeInType #-} module Lib where import Data.Kind class Contravariant f where contramap :: (a -> b) -> f b -> f a dimap :: (Contravariant (p :: * -> b -> p * b), Functor (p a)) => (z -> a) -> (b -> c) -> p a b -> p z c dimap f g = contramap f . fmap g }}} I have no idea if it should compile or not, but it shouldn't do this: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): piResultTy k_a34u[tau:1] * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:947:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13861: Take more advantage of STG representation invariance (follows up #9291)
by GHC 05 Oct '18

05 Oct '18

#13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider following `case` alternatives at the STG stage (i.e. untyped) : {{{#!hs case scrut of False -> [] Just x -> Right x [] -> Nothing }}} The common theme of all these is that the scrutinee's memory layout and the result's memory layout coincide. So operationally no allocation needs to take place, and the whole `case` expression is simply a (strict) identity at the STG stage. I propose to add a small STG analysis to: * for each `case` alternative check whether the assigned tag between scrutinee and result matches, and if so * check whether both have the underlying memory layout and contents. If these conditions are met, the case alternative can be replaced with the identity. When all alternatives simplify to the identity (also considering the DEFAULT alternative), then the entire `case` expression reduces to a single identity DEFAULT alternative (i.e. all other alternatives in the `case` can be dropped). Many of the code examples in the join points paper (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/join- points-pldi17.pdf) exhibit these optimisation opportunities. The already implemented suggestion in #9291 comes with the restriction that it only operates in the scope of the same type (see last comment there), but STG is untyped, so why not take advantage of this fact? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13861> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14391: Make the simplifier independent of the typechecker
by GHC 05 Oct '18

05 Oct '18

#14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: newcomer | 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 noticed that the simplifier module depends on all of the type checker, and HsSyn stuff, and renamer stuff, which I found strange. After a little investigation, it seems that the simplifier depends on CoreMonad, and that pulls some very few type-checker related things: 1. {{{ import TcRnMonad ( initTcForLookup ) import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) }}} for {{{ thNameToGhcName :: TH.Name -> CoreM (Maybe Name) thNameToGhcName th_name = do hsc_env <- getHscEnv liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) }}} which is not even used in GHC, but only in GHC Plugins, so this could probably be moved to a separate module pulled in by GhcPlugins.hs 2. {{{ import TcEnv ( lookupGlobal ) }}} for {{{ instance MonadThings CoreM where lookupThing name = do { hsc_env <- getHscEnv ; liftIO $ lookupGlobal hsc_env name } }}} This might be a bit harder to disentangle. But if successful, it would probably make building GHC in parallel quite a bit faster. And it just seems strange to me that the Core-to-Core code should depend on the type checker… Simon says: > Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup. I am optimistically marking this as `newcomer` because it is a refactoring task, and a good way of learning a bit about various pieces, with a reasonably clear notion of “success”. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 44

[GHC] #15383: T3171 doesn't terminate with Interrupted message on Darwin
by GHC 04 Oct '18

04 Oct '18

#15383: T3171 doesn't terminate with Interrupted message on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 am seeing `T3171` fail with incorrect stderr output on Darwin (e.g. https://circleci.com/gh/ghc/ghc/7106) {{{ Actual stdout output differs from expected: --- ./ghci/should_run/T3171.run/T3171.stdout.normalised 2018-07-14 21:24:25.000000000 -0700 +++ ./ghci/should_run/T3171.run/T3171.run.stdout.normalised 2018-07-14 21:24:25.000000000 -0700 @@ -1 +0,0 @@ -Interrupted. *** unexpected failure for T3171(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15235: GHCi's claim of infixr 0 (->) is a lie
by GHC 04 Oct '18

04 Oct '18

#15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Currently, if you query the `:info` for `(->)` in GHCi, it will give you: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> :i (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr 0 `(->)` <instances elided> }}} This fixity information appears to be plain wrong, as the following program demonstrates: {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where import Data.Type.Equality type (~>) = (->) infixr 0 ~> f :: (a ~> b -> c) :~: (a ~> (b -> c)) f = Refl }}} Since `(~>)` and `(->)` are both `infixr 0`, I would expect `a ~> b -> c` to associate as `a ~> (b -> c)`, like the type signature for `f` wants to prove. However, GHC believes otherwise: {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:5: error: • Occurs check: cannot construct the infinite type: a ~ a ~> b Expected type: ((a ~> b) -> c) :~: (a ~> (b -> c)) Actual type: ((a ~> b) -> c) :~: ((a ~> b) -> c) • In the expression: Refl In an equation for ‘f’: f = Refl • Relevant bindings include f :: ((a ~> b) -> c) :~: (a ~> (b -> c)) (bound at Bug.hs:10:1) | 10 | f = Refl | ^^^^ }}} Reading the error message above, it appears that GHC gives `(->)` an even //lower// precedence than 0, since it associates `a ~> b -> c` as `(a ~> b) -> c`. I'm not sure how to reconcile these two facts. There are at least a couple of options I can think of: 1. Claim `(->)` has a negative fixity. 2. Try to change GHC so that `(->)` really is `infixr 0`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8708: Kind annotation in tuple not parsed
by GHC 04 Oct '18

04 Oct '18

#8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider this: {{{ {-# LANGUAGE KindSignatures #-} foo :: (Int, Int :: *) foo = undefined }}} HEAD reports {{{ /Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’ }}} Changing the line to {{{ foo :: (Int, (Int :: *)) }}} fixes the problem. Note the extra parentheses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5