- ghc-tickets - Haskell.org

[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

[GHC] #14996: Typed holes are very slow
by GHC 14 Apr '18

14 Apr '18

#14996: Typed holes are very slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- If you type at the GHCi prompt {{{ ghci> 3 _ 4 }}} (which I did for #14969), you get a multi-second pause before the error message comes out. I think this is because the error-message generator is looking through the entire type environment. But it's really too slow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error
by GHC 14 Apr '18

14 Apr '18

#15037: Running 1 twice, followed by a typed hole, in GHCi causes internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Keywords: TypedHoles | 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: -------------------------------------+------------------------------------- Originally reported in https://ghc.haskell.org/trac/ghc/ticket/14996#comment:2. You need GHC HEAD (i.e., more recent than GHC 8.4.1) to trigger this: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180413: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> 1 1 λ> 1 1 λ> _ <interactive>:1:1: error: GHC internal error: ‘Ghci1.it’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} And yes, running `1` //twice// seems to be critical to triggering this bug, for some reason. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15036: STG Linter dies when linting primitive
by GHC 14 Apr '18

14 Apr '18

#15036: STG Linter dies when linting primitive -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- Steps to reproduce: - Check out the master branch of primitive. Commit hash is currently 6b49e83fef0126ac09db7acf47f16df43ebce61b. - `cabal new-build -w ghc-8.4.1 --ghc-options -dstg-lint` - The impossible happened Ben, I saw that you had been fixing the stg linter so I'm CCing you in case this is related to your work on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15035: Panic when using StaticPointers with typed holes
by GHC 14 Apr '18

14 Apr '18

#15035: Panic when using StaticPointers with typed holes -------------------------------------+------------------------------------- Reporter: utdemir | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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: -------------------------------------+------------------------------------- Adding a type hole when there is a type variable in `StaticPtr` throws a GHC panic: {{{#!hs {-# LANGUAGE StaticPointers #-} module Foo where import Data.Typeable import GHC.StaticPtr foo :: Typeable a => StaticPtr a foo = static _ }}} {{{ [1 of 1] Compiling Foo ( test.hs, test.o ) test.hs:9:14: error:ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): No skolem info: [a_aD2[sk:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2945:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panics on both GHC 8.2.2 and 8.4.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1