- ghc-tickets - Haskell.org

[GHC] #12671: enumFrom error thwarts checkOldIface's exception handling
by GHC 07 Oct '16

07 Oct '16

#12671: enumFrom error thwarts checkOldIface's exception handling -------------------------------------+------------------------------------- Reporter: ezyang | 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: -------------------------------------+------------------------------------- This bug needs a bit of jiggery-pokery to reproduce. First, we need to create a malformed hi file that we will feed `checkOldIface`. First, have a fresh build of GHC. Apply the following diff to your tree: {{{ diff --git a/compiler/main/HscTypes.hs b/compiler/main/HscTypes.hs index 7a585f3..4e41887 100644 --- a/compiler/main/HscTypes.hs +++ b/compiler/main/HscTypes.hs @@ -1033,7 +1033,8 @@ instance Binary ModIface where put_ bh vect_info put_ bh hpc_info put_ bh trust - put_ bh trust_pkg + putByte bh 3 + -- put_ bh trust_pkg get bh = do mod <- get bh }}} Next, rebuild ONLY the stage 2 compiler using `cd ghc; make stage=2 -j12 fast`. Now, use the new stage2 compiler to compile some module (it can be empty): {{{ [ezyang@hs01 ghc-backpack]$ inplace/bin/ghc-stage2 -c A.hs [ezyang@hs01 ghc-backpack]$ inplace/bin/ghc-stage2 -c A.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161006 for x86_64-unknown-linux): Prelude.Enum.Bool.toEnum: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} With `-v3`, we see that this error occurred when checking the old interface: {{{ [ezyang@hs01 ghc-backpack]$ inplace/bin/ghc-stage2 -c A.hs -v3 Glasgow Haskell Compiler, Version 8.1.20161006, stage 2 booted by GHC version 8.0.1 Using binary package database: /home/hs01/ezyang/ghc- backpack/inplace/lib/package.conf.d/package.cache package flags [] loading package database /home/hs01/ezyang/ghc- backpack/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: *** Checking old interface for A: }}} Dastardly. We've choked checking the old interface! The problem seems to be that the `toEnum` exception is not an `IOException`, so we don't catch it in `tryMost` (which `readIface` uses to catch errors). Funnily enough, the comment above says precisely, `TODO: I'm not entirely sure if this is catching what we really want to catch`. But to catch these, we'll have to catch all `UserError`s (because that is what is being thrown in this case.) Maybe a bridge too far? Another possibilty is to use some home-baked `toEnum` which catches errors of this sort. Anyway, the fix should be simple, we just have to decide what to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9547: Empty constraint tuples are mis-kinded
by GHC 07 Oct '16

07 Oct '16

#9547: Empty constraint tuples are mis-kinded -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ -- If :: forall k. 'Bool -> k -> k -> k type family If cond tru fls where If True tru fls = tru If False tru fls = fls foo :: If True () (Eq a) => a -> a foo = error "urk" }}} This should work fine. But we get {{{ Foo.hs:8:21: The third argument of `If' should have kind `*', but `Eq a' has kind `Constraint' In the type signature for `foo': foo :: If True () (Eq a) => a -> a }}} Reason: GHC is treating the `()` unit tuple as of kind `*`. Reason is that in the `HsTupleTy` case of `tc_hs_type` in `TcHsType`, we see {{{ -- In the [] case, it's not clear what the kind is, so guess * }}} And that guess is plain wrong in this case. Unfortunately I don't see an easy fix, but it's plain wrong as-is. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12395: Misleading GHCi errors when package is installed
by GHC 07 Oct '16

07 Oct '16

#12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a package is installed in a cabal sandbox/global package directory and code is loaded with GHCi when a file has been deleted, GHCi gives very misleading errors. First, if we don't install the package, we get the correct error/expected result: {{{ > mv B.hs B.hs.old > ghci Main.hs Main.hs:3:1: error: Failed to load interface for ‘B’ Use -v to see a list of the files searched for. Failed, modules loaded: A. }}} But if we first install the package, we get a very strange error: {{{ > mv B.hs.old B.hs > cabal install > mv B.hs B.hs.old > ghci Main.hs Main.hs:6:14: error: Ambiguous occurrence ‘str’ It could refer to either ‘A.str’, imported from ‘A’ at Main.hs:2:1-8 (and originally defined at A.hs:7:1-3) or ‘B.str’, imported from ‘B’ at Main.hs:3:1-8 (and originally defined in ‘A’) Failed, modules loaded: A. }}} I'm using GHC 8.0.1, cabal-install-1.24.0.0, and Cabal Library-1.24.0.0. This is Very Annoying because I use this process to minimize examples. For example, when I want to simplify code by removing a module, I just delete it and then rely on GHCi to tell me what I need to update. Anyone not aware of this bug would be totally confused by the error, and even though I do know about the bug, the error is completely unhelpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12130: ghc: panic! (the 'impossible' happened): find_tycon Block []
by GHC 06 Oct '16

06 Oct '16

#12130: ghc: panic! (the 'impossible' happened): find_tycon Block [] -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to {{{$(widgetFile ...)}}} yesod template haskell clause. It was same on linux and windows, and when I remove handler ghc fails at Application module (and seems also due to template haskell). {{{ ~/yt> stack build ... yt-0.0.0: configure Configuring yt-0.0.0... yt-0.0.0: build Preprocessing library yt-0.0.0... [1 of 9] Compiling Settings ( Settings.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings.o ) [2 of 9] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings/StaticFiles.o ) [3 of 9] Compiling Import.NoFoundation ( Import/NoFoundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import/NoFoundation.o ) [4 of 9] Compiling Foundation ( Foundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Foundation.o ) [5 of 9] Compiling Import ( Import.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import.o ) [6 of 9] Compiling Handler.Common ( Handler/Common.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Common.o ) [7 of 9] Compiling Handler.Home ( Handler/Home.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 179 action(s). -- While building package yt-0.0.0 using: /home/jeiea/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:yt exe:yt --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12666: ApplicativeDo fails to sequence actions
by GHC 06 Oct '16

06 Oct '16

#12666: ApplicativeDo fails to sequence actions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider the following, {{{#!hs {-# LANGUAGE ApplicativeDo #-} module Fail where data P a = P instance Functor (P) where fmap _ P = P instance Applicative (P) where P <*> P = P pure _ = P action :: P Int action = P works :: P (Int, Int) works = do a <- action b <- action return (a,b) thisWorks :: P Int thisWorks = action *> action -- It seems like this should be equivalent to thisWorks. shouldThisWork :: P Int shouldThisWork = do action action }}} It seems to me that `thisWorks` and `shouldThisWork` are equivalent, yet the latter fails to typecheck. It seems that `ApplicativeDo` fails to catch this the fact that the result of the first `action` is unbound and therefore can be sequenced with `*>`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12667: Compiling haskell-stack crashes the compiler
by GHC 06 Oct '16

06 Oct '16

#12667: Compiling haskell-stack crashes the compiler -------------------------------------+------------------------------------- Reporter: hudon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When upgrading haskell-stack using brew, I get: {{{ ==> Upgrading haskell-stack ==> Downloading https://github.com/commercialhaskell/stack/releases/download/v1.1.2/stack-1… Already downloaded: /Users/hudon/Library/Caches/Homebrew/haskell- stack-1.1.2.tar.gz ==> cabal sandbox init ==> cabal update ==> cabal install --jobs=8 --max-backjumps=100000 Last 15 lines from /Users/hudon/Library/Logs/Homebrew/haskell- stack/03.cabal: [ 1 of 87] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, dist/dist- sandbox-7d57129e/build/Stack/FileWatch.o ) [ 2 of 87] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/dist-sandbox- 7d57129e/build/System/Process/PagerEditor.o ) [ 3 of 87] Compiling System.Process.Log ( src/System/Process/Log.hs, dist /dist-sandbox-7d57129e/build/System/Process/Log.o ) [ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-7d57129e/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/lc/jm4g8s190gl8977h7tz9j6tc0000gn/T/ghc18925_0/libghc_44.dylib, 5): no suitable image found. Did find: /var/folders/lc/jm4g8s190gl8977h7tz9j6tc0000gn/T/ghc18925_0/libghc_44.dylib: malformed mach-o: load commands size (40304) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12656: ghci floats out constant despite -fno-cse, resulting in very unintuitive behaviour
by GHC 05 Oct '16

05 Oct '16

#12656: ghci floats out constant despite -fno-cse, resulting in very unintuitive behaviour -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program using `Data.Vector.unsafeThaw` and `-fno-cse`: {{{ {-# OPTIONS_GHC -fno-cse #-} import qualified Data.Vector as V import qualified Data.Vector.Mutable as VM main :: IO () main = do foo 100000 foo 100000 foo :: Int -> IO () foo n = do indexVector <- V.unsafeThaw $ V.generate n id x <- VM.read indexVector 5 VM.write indexVector 5 (x * x) print x -- In GHCI, we get: -- -- > :set -fno-cse -- -- > foo 100000 -- 5 -- > foo 100000 -- 5 -- -- > let f = foo 100000 in f >> f -- 5 -- 25 }}} I would expect that {{{ > let f = foo 100000 in f >> f 5 5 }}} Shouldn't `-fno-cse` fix this? (Note: With `ghc` instead of `ghci`, we don't observe this behaviour.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12659: Unactionable core lint warning due to floating out
by GHC 05 Oct '16

05 Oct '16

#12659: Unactionable core lint warning due to floating out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 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 was looking through the build log to try and make it a bit less noisy by removing some warnings. There were quite a lot of core lint warnings which complain about INLINE progams on loop breakers. However, sometimes these bindings are not marked INLINE at the source level but by GHC itself. {{{ cmmDebugLink :: [Label] -> [DebugBlock] -> [DebugBlock] cmmDebugLink labels blocks = map link blocks where blockPos :: LabelMap Int blockPos = mapFromList $ flip zip [0..] labels link block = block { dblPosition = mapLookup (dblLabel block) blockPos , dblBlocks = map link (dblBlocks block) } }}} For example, in this function, `link` gets floated out to the top level and then marked as `INLINE` even though it is self-recursive. This causes the following warning: {{{ *** Core Lint warnings : in result of CorePrep *** 5170 <no location info>: warning: 5171 [RHS of link_slxp :: DebugBlock -> DebugBlock] 5172 INLINE binder is (non-rule) loop breaker: link_slxp 5173 }}} But because it's generated by the compiler, there isn't a sensible way to suppress the warning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12659> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 05 Oct '16

05 Oct '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks Reid! Yet another reason to move to hpp, I suppose. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call
by GHC 05 Oct '16

05 Oct '16

#12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This can save lots of time when the cost to invoke a single GHC command is high, for example through docker. An example user of this would be `stack build`, which will unregister all relevant packages if e.g. `--extra-lib-dirs` has changed. Currently it has to do that through multiple `ghc-pkg unregister` operations, which can take about 2 seconds per call when done through a docker image. If we could unregister multiple packages at once, such use cases would have to pay the 2 seconds penalty only once. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5