- ghc-tickets - Haskell.org

[GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin
by GHC 13 Oct '18

13 Oct '18

#15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple typeable,knownnat | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} module Nats where import Data.Proxy (Proxy (..)) import Data.Typeable (Typeable) import GHC.TypeLits (KnownNat, type (+)) f :: forall n . (Typeable n, KnownNat n) => Proxy n -> () f _ = () f _ = f (Proxy :: Proxy (n + 1)) }}} When I try to compile this code I observe the following error message: {{{ • Could not deduce (Typeable (n + 1)) arising from a use of ‘f’ from the context: (Typeable n, KnownNat n) bound by the type signature for: f :: forall (n :: ghc-prim-0.5.2.0:GHC.Types.Nat). (Typeable n, KnownNat n) => Proxy n -> () at src/Nats.hs:13:1-57 • In the expression: f (Proxy :: Proxy (n + 1)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (n + 1)) | 15 | f _ = f (Proxy :: Proxy (n + 1)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This code works for both GHC-8.2.2 and GHC-8.0.2. I found similar ticket with exactly this problem but looks like this is broken again: #10348 (bug). Originally reported at Github for `ghc-typelits-knownnat` package: * https://github.com/clash-lang/ghc-typelits-knownnat/issues/21 `ghc-typelits-knownnat` package correctly infers `KnownNat (n + 1)` constraint so GHC should be able to infer `Typeable (n + 1)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning
by GHC 12 Oct '18

12 Oct '18

#15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This example {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern Foo :: a -> b -> (a, b) pattern Foo a b = (a, b) {-# complete Foo #-} main :: IO () main = case ((), Nothing :: Maybe Integer) of ((), Just x) -> print x }}} doesn't give a warning for the incomplete pattern match in {{{main}}}, which doesn't involve textually the pattern synonym {{{Foo}}}. Removing the complete pragma or changing the expression being matched on to even {{{(,) () (Nothing :: Maybe Integer)}}} allows the warning -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15476: Add -fwarn-star-is-type to -Wcompat
by GHC 12 Oct '18

12 Oct '18

#15476: Add -fwarn-star-is-type to -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- According to the accepted proposal https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0030-remove-star-kind.rst This change must be included in 8.8, but I think it won't do any harm to include it in GHC 8.6 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.
by GHC 12 Oct '18

12 Oct '18

#13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. --------------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Currently GHC HEAD segfaults on Windows 64-bit when compiling `language-c-quote-0.11.7.1` package. It spits something like `Access violation in generated code when executing data at 0000000102fbcf40` (I'm using my #13108 patch here). After repeated run, when GHC hasn't recompile all files, but only part of them, it succeeds. If I delete intermediate files and repeat clean compilation, it segfaults again. Haddock always segfaults (since it always recompile all files), more details here: https://github.com/haskell/haddock/pull/568. Since these access violations consistently happen on executable data at virtual addresses above 4GB mark, this very much smells as a GHC bytecode generator/linker issue. I believe, GHC and Haddock succeed exactly when all executable addresses stay below 4GB mark. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #15742: GHC configure step can fail when CC=clang
by GHC 12 Oct '18

12 Oct '18

#15742: GHC configure step can fail when CC=clang ----------------------------------------+--------------------------------- Reporter: judah | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In our internal build of GHC from source, we are building it on Linux with Clang. Unfortunately, this results in an error on ghc-8.4.3: {{{ $ ./configure CC=clang CC_STAGE0=clang --prefix=... --with-ghc=... ... checking version of gcc... configure: error: Need at least gcc version 4.4 (4.7+ recommended) }}} Looking in the code, it seems that the logic is wrong: it calls `$CC -v` and parses the output unconditionally, whether or not the compiler is actually GCC: https://github.com/ghc/ghc/blob/ce7a1c4ae4c93f2d0d3d7a0b573ddd876fc855c2/ac… In our case, the test fails since the compiler is a build of Clang that doesn't produce a useful version number. I also realized that on macOS (where gcc *is* clang), this test succeeds accidentally, since the output of {{{gcc -v}}} is: {{{ Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with- gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin judahjacobson-macbookpro:~ judahjacobson$ gcc -v Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with- gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15741: Accept GHCRTS=-N1 when not compiled with -threaded
by GHC 12 Oct '18

12 Oct '18

#15741: Accept GHCRTS=-N1 when not compiled with -threaded -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.6.1 System | 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: -------------------------------------+------------------------------------- current behaviour: {{{ > ghc Main.hs -o test > ./test +RTS -N1 test: the flag -N1 requires the program to be built with -threaded [blah blah] }}} requested: {{{ > ghc Main.hs -o test > ./test +RTS -N1 hello world }}} Motivation: In certain environments, threaded is bad idea due to resource constraints even when multiple capabilities are available, because resident memory can increase with parallel execution. Slapping GHCRTS=-N1 onto those environments would be nice, but breaks for things not compiled with -threaded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code
by GHC 12 Oct '18

12 Oct '18

#15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At ICFP, I griped to Ben about some code I'm writing (which makes use of `singletons` to the nth degree) that takes absolutely forever to compile with optimizations. I suspected that type families (i.e., coercions) were the culprit, but Ben requested that I put the code on Trac anyways, so here it is. I've attached two modules (`Lib.hs` and `Lib2.hs`). You'll need GHC 8.6.1 or later to compile it. To compile it, run: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 3m28.367s user 3m28.512s sys 0m0.212s }}} Note that if you compile without optimizations, it'll finish almost immediately: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O0 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.528s user 0m0.480s sys 0m0.036s }}} Also, if you look at the source code for `Lib.hs`, you'll notice some code which says: {{{#!hs instance SApplicative f => SApplicative (M1 i c f) where sPure x = singFun3 @(.@#@$) (%.) @@ singFun1 @M1Sym0 SM1 @@ (singFun1 @PureSym0 sPure) @@ x -- If I change the implementation of sPure above to be this: -- -- sPure x = SM1 (sPure x) -- -- Then Lib.hs compiles quickly again (< 1 second) with -O1. SM1 f %<*> SM1 x = SM1 (f %<*> x) }}} If you apply this suggested change, then you can see the difference when you compile it with optimizations again: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.986s user 0m0.940s sys 0m0.040s }}} Given that this particular change of code causes such a dramatic increase in compilation, I have to wonder if there's more going on here than just the usual type-family slowness. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15739: ghc-heap: code field never seems to be populated in StgInfoTable
by GHC 11 Oct '18

11 Oct '18

#15739: ghc-heap: code field never seems to be populated in StgInfoTable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- It seems that `peekItbl` doesn't populate the `code` field of `StgInfoTable`. https://github.com/ghc/ghc/blob/6bb9bc7d3c935dcb77e0700cce28de2c9df646df/li… /ghc-heap/GHC/Exts/Heap/InfoTable.hsc#L52 If you look at `InfoTables.h`, when `TABLES_NEXT_TO_CODE`, it should be populated. https://github.com/ghc/ghc/blob/1c2c2d3dfd4c36884b22163872feb87122b4528d/in… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15737: Implement sconcat Semigroup Instances for Tuples
by GHC 11 Oct '18

11 Oct '18

#15737: Implement sconcat Semigroup Instances for Tuples -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- For some semigroups, the user-defined `sconcat` performs asymptotically better than the default. The semigroup instances for tuples should create a list of each component individually, use `sconcat` for the underlying type, and then zip the tuples back together. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15603: ref6 example from StaticPointers documentation doesn't type check
by GHC 11 Oct '18

11 Oct '18

#15603: ref6 example from StaticPointers documentation doesn't type check -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts… #extension-StaticPointers documentation] for `StaticPointers` contains the following example. {{{ ref6 y = let x = 1 in static x }}} but this doesn't get accepted by the type checker. {{{ sp.hs:27:23: error: • ‘x’ is used in a static form but it is not closed because it has a non-closed type because it contains the type variables: ‘p_a7KP’ • In the expression: static x In the expression: let x = 1 in static x In an equation for ‘ref6’: ref6 y = let x = 1 in static x | 27 | ref6 y = let x = 1 in static x | ^^^^^^^ }}} I tested on 8.6.1, 8.4.3, 8.2.2, 8.02, 7.10.3 and all fail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9