April 2018 - ghc-tickets

[GHC] #11117: mdo blocks in error messages are shown modified
by GHC 17 Apr '18

17 Apr '18

#11117: mdo blocks in error messages are shown modified -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RecursiveDo #-} main = mdo Just x <- return (Right x) return () }}} gives {{{ MdoTypeError.hs:3:3: Couldn't match expected type ‘Either a0 b0’ with actual type ‘Maybe b0’ Relevant bindings include x :: b0 (bound at MdoTypeError.hs:3:8) In the pattern: Just x In a stmt of an 'mdo' block: Just x <- return (Right x) In a stmt of an 'mdo' block: rec { Just x <- return (Right x) } }}} Note that the error message mentions `rec` even though that is not what the user entered. In other instances, we are careful to show the code more similar to the original (e.g. `do`-notation instead of `>>=`). This should also be done here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15044: Option to output instance resolution process
by GHC 16 Apr '18

16 Apr '18

#15044: Option to output instance resolution process -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple debug,typeclasses | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Would it be possible to see what instances get picked by the constraint solver? For example, see coq's `Set Typeclass Debug.`. The following comment also shows what it might look like: https://www.reddit.com/r/haskell/comments/8cmn4i/algorithmically_scrapping_… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14750: Plugins should be loaded once for each module rather than multiple times
by GHC 16 Apr '18

16 Apr '18

#14750: Plugins should be loaded once for each module rather than multiple times -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: plugins | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Plugins are currently loaded immediately before they are used in the simplifier and constraint solver. It would be better to load them once, at the start of the pipeline rather than at each of these different places. lazer already has a patch which achieves this. I'm making it a separate ticket as it need not be blocked on the progress of #14709 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15023: GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release
by GHC 16 Apr '18

16 Apr '18

#15023: GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | 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: -------------------------------------+------------------------------------- Despite https://ghc.haskell.org/trac/ghc/ticket/14699#comment:25 it appears that GHC 8.4.1 shipped with bf4af114ba3d35b2937fc74926aa49e128dd6c1f (which doesn't correspond to any released version) instead of the expected `v2.2.2` tagged c7d396732bd45e409478bd4df1d0ca95d6f39356 commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13360: Add a flag to enable inferring HasCallStack constraints
by GHC 16 Apr '18

16 Apr '18

#13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) 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: -------------------------------------+------------------------------------- GHC is careful to not infer a HasCallStack constraint for a function, because the user didn't ask for one, it would complicate the type, and because it would incur some runtime overhead. I think this is the right default, but it can make debugging exceptions tedious as you have to manually add HasCallStack constraints to the entire chain of functions in the stack. I sometimes use CPP to give myself a flag to toggle the constraints, but I'd rather not have to resort to CPP. Instead, it would be nice if GHC supported a `-finfer-hascallstack` flag (off by default) that would simply generalize over the HasCallStack constraints rather than defaulting them. Then, if my program blows up I can simply recompile with `-finfer-hascallstack` and get a more informative trace. No manual editing, no preparation with CPP, easy! Furthermore, if we had such a flag, it might be nice to '''enable''' it by default in ghci. The two prime concerns are 1. Complicating type signatures. But `:t` solves the HasCallStack constraint before printing the type, so this is only a concern if you use `:i`. 2. Runtime overhead. I don't think this is a valid concern in ghci. I think this would be a nice and simple improvement to the debugging experience. The downside is that even with `-finfer-hascallstack` you would not get full call-stacks for functions in an imported module that was compiled normally. So this would not help with e.g. partial functions in `base`. (It would be really nice to find a solution to this that doesn't involve building modules in multiple ways..) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

[GHC] #15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0
by GHC 14 Apr '18

14 Apr '18

#15005: GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0 -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2-rc1 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: -------------------------------------+------------------------------------- When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows: {{{ [ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist- newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order- maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o ) [ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist- newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order- maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): StgCmmEnv: variable not found x_a46z local binds for: $tc'Label $tcLabel $tc'Cell $tcCell $trModule $tc'Cell1 $tc'Cell2 $tc'Cell3 $trModule1 $trModule2 $trModule3 $trModule4 $tc'Label1 $tc'Label2 $tc'Label3 $tcCell1 $tcCell2 $tcLabel1 $tcLabel2 lvl_r4UD lvl1_r4UE lvl2_r4UF lvl3_r4UG lvl4_r4UH lvl5_r4UI lvl6_r4UJ lvl7_r4UK lvl8_r4UL lvl9_r4UM lvl10_r4UN lvl11_r4UO lvl12_r4UP lvl13_r4UQ lvl14_r4UR lvl15_r4US lvl16_r4UT lvl17_r4UU $krep_r4UV $krep1_r4UW $krep2_r4UX lvl18_r4UY $krep3_r4UZ $krep4_r4V0 $krep5_r4V1 $krep6_r4V2 $krep7_r4V3 $krep8_r4V4 $krep9_r4V5 lvl19_r4V6 lvl20_r4V7 lvl21_r4V8 lvl22_r4V9 lvl23_r4Va lvl24_r4Vb lvl25_r4Vc ww_s4W2 lwild_s4W3 lwild1_s4W4 noOfLabels_s4W5 noOfLabels1_s4W6 labelMask_s4W7 $wnewAfterCell_s4Wa ww1_s4Wb ipv1_s4Wf wild_s4Wg ds_s4Wh ds2_s4Wi ww2_s4Wk ww3_s4Wl ww4_s4Wn ww5_s4Wo wild1_s4Wq smallGap_s4Wr wild2_s4Ws Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The same problem exists with GHC 8.4.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14936: GHC 8.4 performance regressions when using newtypes
by GHC 14 Apr '18

14 Apr '18

#14936: GHC 8.4 performance regressions when using newtypes -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Here is some serious performance regression in the following code: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-} module Main where import Prelude import qualified Foreign.Storable as Storable import qualified Control.Monad.State.Strict as S import Control.Monad.IO.Class import Foreign.Marshal.Alloc (mallocBytes) import Criterion.Main newtype Foo a = Foo a intSize :: Int intSize = Storable.sizeOf (undefined :: Int) slow :: Int -> IO () slow i = do ptr <- mallocBytes $ 2 * intSize Storable.pokeByteOff ptr intSize (0 :: Int) let go 0 = pure () go j = do Foo (!_, !off) <- S.get !(x :: Int) <- liftIO $ Storable.peekByteOff ptr off liftIO $ Storable.pokeByteOff ptr off $! (x + 1) go (j - 1) S.evalStateT (go i) (Foo ((0::Int),(intSize::Int))) fast :: Int -> IO () fast i = do ptr <- mallocBytes $ 2 * intSize Storable.pokeByteOff ptr intSize (0 :: Int) let go 0 = pure () go j = do (!_, !off) <- S.get !(x :: Int) <- liftIO $ Storable.peekByteOff ptr off liftIO $ Storable.pokeByteOff ptr off $! (x + 1) go (j - 1) S.evalStateT (go i) ((0::Int),(intSize::Int)) main :: IO () main = defaultMain [ bgroup "slow" $ (\(i :: Int) -> bench ("10e" <> show i) $ perRunEnv (return ()) $ \v -> slow (10 ^ i)) <$> [7..8] , bgroup "fast" $ (\(i :: Int) -> bench ("10e" <> show i) $ perRunEnv (return ()) $ \v -> fast (10 ^ i)) <$> [7..8] ] }}} Compiled with flags: `-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -fexcess-precision -fexpose-all-unfoldings -flate-dmd-anal -fspec-constr- keen -fspecialise-aggressively -fstatic-argument-transformation -fmax- worker-args=200` The `slow` function executes 2 times slower than the `fast` one. The only difference is that the state is wrapped in a newtype. It was working properly in GHC 8.2 (both functions were equally fast - as fast as the current `fast` function). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14936> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15002: Panic: collectNBinders
by GHC 14 Apr '18

14 Apr '18

#15002: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.4.2-rc1 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: -------------------------------------+------------------------------------- Steps to reproduce: Download concurrent-extra-0.7.0.12 and add the following stack.yaml file: resolver: nightly-2018-04-04 system-ghc: true compiler-check: newer-minor {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.1.20180329 > stack build --library-profiling concurrent-extra-0.7.0.12: build (lib) Preprocessing library for concurrent-extra-0.7.0.12.. Building library for concurrent-extra-0.7.0.12.. [7 of 8] Compiling Control.Concurrent.Broadcast ( Control/Concurrent/Broadcast.hs, .stack- work/dist/x86_64-linux/Cabal-2.2.0.1/build/Control/Concurrent/Broadcast.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1.20180329 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2189:39 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package concurrent-extra-0.7.0.12 using: /home/local/ANT/ericcro/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_2.2.0.1_ghc-8.4.1.20180329 --builddir=.stack- work/dist/x86_64-linux/Cabal-2.2.0.1 build lib:concurrent-extra --ghc- options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15025: Lingering @since TODO Haddock annotations
by GHC 14 Apr '18

14 Apr '18

#15025: Lingering @since TODO Haddock annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: libraries | Version: 8.4.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are currently a handful of `@since TODO` annotations in Haddocks throughout the core libraries that were probably intended to be replaced with a real version at some point, but managed to slip through the cracks into the GHC 8.4.1 release: * `FixIOException` in `base`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec… * `powModSecInteger` in `integer-gmp`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec… /integer-gmp/src/GHC/Integer/Type.hs#l1454 We should fix these before GHC 8.4.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14947: internal error: Invalid object *c in push()
by GHC 14 Apr '18

14 Apr '18

#14947: internal error: Invalid object *c in push() -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce on Windows 10 x64: {{{ stack --version Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0 git clone https://github.com/varosi/cgraytrace.git cd cgraytrace git checkout 8c9499e4f3b1ba18b71e499667e865bb6db61856 stack build --profile stack exec --rts-options="-hr" -- cgraytrace-exe Rendering to sample.png... cgraytrace-exe.EXE: internal error: Invalid object *c in push() (GHC version 8.4.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12