December 2016 - ghc-tickets

[GHC] #12096: Attach stacktrace information to SomeException
by GHC 02 Aug '18

02 Aug '18

#12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Now (base 4.9.0.0) ErrorCall contain field for stacktrace information and error fills it. If you add field for stacktrace information to SomeException {{{#!hs data SomeException where SomeExceptionWithLocation :: Exception e => String -> e -> SomeException pattern SomeException :: () => Exception e => e -> SomeException pattern SomeException err <- SomeExceptionWithLocation _ err where SomeException err = SomeExceptionWithLocation "" err }}} and will fills it in throw {{{#!hs throw :: (HasCallStack, Exception e) => e -> a throw e = unsafeDupablePerformIO $ do stack <- currentCallStack raise# (CallStackException e $ if stack /= [] then prettyCallStack ?callStack ++ "\n" ++ renderStack stack else prettyCallStack ?callStack) }}} it will be more useful for ghci users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #11759: can't decompose ghc.exe path
by GHC 02 Aug '18

02 Aug '18

#11759: can't decompose ghc.exe path --------------------------------------+---------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{ erisco@ERICWIN C:\Users\erisco\haskell-platform-bin $ ghc.exe ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "C:\\Users\\erisco\\haskell- platform-bin\\ghc.exe" }}} haskell-platform-bin is a symbolic directory link to "C:\Program Files\Haskell Platform\2014.2.0.0\bin". I did this so there would not be spaces in the path because this is causing other issues for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of *
by GHC 31 Jul '18

31 Jul '18

#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: TypeInType | 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 is premature but what the darn, {{{ >>> :kind Maybe Maybe :: Type -> Type >>> :kind StateT StateT :: Type -> (Type -> Type) -> Type -> Type >>> :kind Eq Eq :: Type -> Constraint >>> :info Functor class Functor (f :: Type -> Type) where ... }}} `*` throws students off and makes it seem scarier than it is. Symbols are harder to search for in general and to understand without documentation, `Type` on the other hand is descriptive. There are valid arguments against displaying `Type`: 1. It's a recent feature subject to change. 2. Although symbols are more difficult to search for, `*` is established in educational materials, logs, blogs and questions. 3. By default `Type` is not in scope so a user cannot ask for information in GHCi. `*` is established and searching for “Haskell asterisk” yields a lot resources but [https://support.google.com/websearch/answer/2466433?hl=en ‘*’ is also a wildcard] in Google and ignored by GitHub. With time `Type` would be a good search term but currently it's chicken-and-the-egg. Previous versions of GHCi error on `:kind *` and `:info *` only shows multiplication so that wouldn't be a huge difference but we can qualify by default: {{{ >>> :kind Maybe Maybe :: Data.Kind.Type -> Data.Kind.Type >>> :kind StateT StateT :: Data.Kind.Type -> (Data.Kind.Type -> Data.Kind.Type) -> Data.Kind.Type -> Data.Kind.Type >>> :kind Eq Eq :: Data.Kind.Type -> Constraint >>> :info Functor class Functor (f :: Data.Kind.Type -> Data.Kind.Type) where ... }}} or display `*` normally and only when `TypeInType` is set do we display `Type`. I don't love it (and love `GHC.Types.Type` slightly less) but there is a precedent for unqualified names, browsing the Prelude for example: {{{#!hs ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b undefined :: forall (r :: GHC.Types.RuntimeRep) (a :: TYPE r). GHC.Stack.Types.HasCallStack => a }}} __If__ the consensus is that this will happen sometime down the line consider that each passing release means many more books and blog posts get written using `*`. I wasn't planning on resulting to scare tactics but [https://www.peoria.com/spaw/spawimages/members/member60763/shoot_this_dog.j… here we are]... ---- If needed a migration plan can be drafted like the Semigroup/FTP/AMP/BBP/MonadFail/expanding Float/... proposals, possibly culminating in `Type` fully replacing `*` and being imported by default. I'm sure there are some further reaching consequences to this and better arguments against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10056: Inconsistent precedence of ~
by GHC 30 Jul '18

30 Jul '18

#10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following compiles as expected: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family Foo a b f :: (Foo a b ~ Int) => a -> b -> b f = error "" }}} but this fails: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family a \\ b f :: (a \\ b ~ Int) => a -> b -> b f = error "" }}} with the error > "The second argument of `(\\)` should have kind `*`, but `b ~ Int` has kind `Constraint`." Thus the first example is being parsed as `(Foo a b) ~ Int`, while the second is parsed as `a \\ (b ~ Int)`. I believe the second example should compile, i.e. `(\\)` and `Foo` should have the same precedence, both of which are higher than `(~)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

[GHC] #11549: Add -fshow-runtime-rep
by GHC 29 Jul '18

29 Jul '18

#11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- As discussed in several interwoven threads ([https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html original], [https://mail.haskell.org/pipermail/haskell- cafe/2016-February/122914.html café]), it has been suggested to add a flag `-fshow-runtime-rep`. Without this flag enabled, the pretty printer will instantiate any `RuntimeRep` type parameters to `PtrRep Lifted`. This has the effect of changing {{{ ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b }}} to {{{ ($) :: (a -> b) -> a -> b }}} under the default GHCi settings. Note that `Levity` becomes `RuntimeRep` after #11471 is complete. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10184: Coercible solver incomplete with recursive newtypes
by GHC 29 Jul '18

29 Jul '18

#10184: Coercible solver incomplete with recursive newtypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.10.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following module fails to compile due to infinite recursion: {{{ import Data.Coerce newtype Bar a = Bar (Either a (Bar a)) newtype Age = MkAge Int x :: Bar Age x = coerce (Bar (Left (5 :: Int))) }}} It tries to coerce `Bar Int` to `Bar Age`. This is clearly doable, via tyconapp decomposition. But we don't find it. Before worrying too much about it, though, we'll wait for a real example. Do speak up if this problem is ruining your day! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9936: Data.Fixed truncates 5.17 to 5.16
by GHC 28 Jul '18

28 Jul '18

#9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `(realToFrac (5.17 :: Double) :: Centi) == 5.16` is true -- it should be false. The offender seems to be the assumption in `fromRational`: `fromRational r = withResolution (\res -> MkFixed (floor (r * (toRational res))))` Uses `floor` assuming that the underlying floating point value is stored purely and not as 0.999999 or similar -- switching it to `round` fixes this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9936> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised
by GHC 28 Jul '18

28 Jul '18

#10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion- | Owner: ninja | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: panic | Operating System: Linux impossible linker initialized | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When trying to build the CUDA accelerate backend I get the following "complier panic": {{{ me@box:~/accelerate-cuda-0.15.0.0$ cabal build Building accelerate-cuda-0.15.0.0... Preprocessing library accelerate-cuda-0.15.0.0... Data/Array/Accelerate/CUDA/CodeGen/Base.hs:5:14: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS [ 7 of 33] Compiling Data.Array.Accelerate.CUDA.CodeGen.Type ( Data/Array/Accelerate/CUDA/CodeGen/Type.hs, dist/build/Data/Array/Accelerate/CUDA/CodeGen/Type.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [ 9 of 33] Compiling Data.Array.Accelerate.CUDA.Debug ( Data/Array/Accelerate/CUDA/Debug.hs, dist/build/Data/Array/Accelerate/CUDA/Debug.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [10 of 33] Compiling Data.Array.Accelerate.CUDA.Analysis.Launch ( Data/Array/Accelerate/CUDA/Analysis/Launch.hs, dist/build/Data/Array/Accelerate/CUDA/Analysis/Launch.o ) <no location info>: <command line>: can't load .so/.DLL for: /home/me/.cabal/lib/x86_64 -linux-ghc-7.10.2/cuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt/libHScuda-0.6.7.0 -EMlxEWvymgZGXnLSaVKypt-ghc7.10.2.so (libcudart.so.7.5: cannot open shared object file: No such file or directory) }}} This is the accelerate cuda package version 0.15.0.0: https://hackage.haskell.org/package/accelerate-cuda I changed the constraints from base==4.7.* to base==4.8.* to allow for compilation with GHC 7.10.2. After installing the dependencies through cabal and attempting to manually build the package manuall with cabal build I get the above mentioned compiler panics. GHC instructed me to report the issue as a bug (defect) so I did. I'd like to get this library to build with the newest version of GHC so please let me know how to proceed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12694: GHC HEAD no longer reports inaccessible code
by GHC 27 Jul '18

27 Jul '18

#12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Given this A.hs: {{{ {-# LANGUAGE GADTs #-} module A where f :: Bool ~ Int => a -> b f x = x }}} I get: {{{ ezyang@sabre:~$ ghc-head --version The Glorious Glasgow Haskell Compilation System, version 8.1.20161010 ezyang@sabre:~$ ghc-head --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:4:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘f’: f x = ... }}} In contrast: {{{ ezyang@sabre:~$ ghc-8.0 --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:3:6: error: • Couldn't match type ‘Bool’ with ‘Int’ Inaccessible code in the type signature for: f :: Bool ~ Int => a -> b • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: f :: Bool ~ Int => a -> b }}} Is this expected? I'd expect at least a warning! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified
by GHC 24 Jul '18

24 Jul '18

#12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified -------------------------------------+------------------------------------- Reporter: bavism | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (FFI) | Keywords: | Operating System: Windows ffi,registers,sse2,clobber,xmm | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: https://github.com/bavis-m/raycast | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the [https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx MSDN], in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer via dynamic wrapper that, when called from MSVC x64 C code, does not preserve these registers, causing further floating-point operations in the C code to fail. I can reproduce this error in [https://github.com/bavis-m/raycast this project], which is a DOOM-style raycasting engine written in Haskell, that imports a C DLL with glue for rendering and window management. The Haskell executable generates a FunPtr to a frame update function using the dynamic import mechanism, and passes this to a long-lived C function that runs the update loop. Any time this update function is called from the C loop, subsequent floating point operations produce incorrect results (in this case, the next operations compute a view matrix for the OpenGL window). The output on every frame showing the view matrix should be: {{{ viewM: 0.003125 0.000000 0.000000 -1.000000 0.000000 0.004167 0.000000 -1.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 }}} Running the raycaster with the Release version of the DLL causes the value of this matrix to be corrupted. There is a patch provided (stub.patch in the root folder) that turns the Haskell update function into an empty stub. This causes the program to work. When stepping through the assembly code with this patch applied, I can see in the function prologue where the XMM registers are saved. Without the patch, these registers are not saved. Running the Debug version does not show this error; the register allocation must be different. I have been attempting to create a much simpler test case to reveal this code-generation issue, however it has been difficult. Even seemingly trivial changes can cause the bug to not show up, it is clearly dependent on the register allocation used internally to produce the assembly code. Instructions for building the project are in the readme. (You will need the Haskell Stack Tool, and Visual Studio 15). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4