- ghc-tickets - Haskell.org

[GHC] #14485: Typo in blog post.
by GHC 21 Nov '17

21 Nov '17

#14485: Typo in blog post. -------------------------------------+------------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Keywords: typo | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.11-released Should be "developers", not "develpoers" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14499: Pattern synonym, (a::k) cannot be written (a::N) given (k ~ N)
by GHC 21 Nov '17

21 Nov '17

#14499: Pattern synonym, (a::k) cannot be written (a::N) given (k ~ N) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I was trying to create a pattern synonym that matches `TypeRep (a::k)` when `k ~ N`, witnessing the equality and returning the representation. This works fine: {{{#!hs {-# Language PatternSynonyms, ViewPatterns, GADTs, ConstraintKinds, RankNTypes, KindSignatures, PolyKinds, ScopedTypeVariables, DataKinds, TypeInType, TypeOperators, TypeApplications #-} import Type.Reflection import Data.Kind foo :: forall (kind::k') (a::k). TypeRep kind -> TypeRep a -> Maybe (kind :~~: k, TypeRep a) foo krep rep = do HRefl <- eqTypeRep krep (typeRepKind rep) pure (HRefl, rep) data N = O | S N pattern Bloop :: forall (a::k). () => N~k => TypeRep (a::k) -> TypeRep (a::k) pattern Bloop rep <- (foo (typeRep @N) -> Just (HRefl, rep :: TypeRep (a::N))) where Bloop rep = rep }}} Note that I have annotated `rep :: TypeRep (a::N)` in the view pattern, which is the first argument to `Bloop`. Let's reflect that in the type {{{#!hs -- error: -- • Expected kind ‘N’, but ‘a’ has kind ‘k’ -- • In the first argument of ‘TypeRep’, namely ‘(a :: N)’ -- In the type ‘TypeRep (a :: N) -> TypeRep (a :: k)’ -- | -- 15 | pattern Bloop :: forall (a::k). () => N ~ k => TypeRep (a::N) -> TypeRep (a::k) -- | ^ pattern Bloop :: forall (a::k). () => N~k => TypeRep (a::N) -> TypeRep (a::k) pattern Bloop rep <- (foo (typeRep @N) -> Just (rep, HRefl)) where Bloop rep = rep }}} Oh no, GHC complains that `a::k` (not `a::N`) but we have local knowledge that `N ~ k`. I know the rules for kinds are weird so I don't know if this is intended. A way around this is quantifying over an existential variable that is heterogeneously equal to `a`: {{{#!hs pattern Bloop :: forall (a::k). () => forall (n::N). a~~n => TypeRep (n::N) -> TypeRep (a::k) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14493: Why is g++ necessary to compile GHC?
by GHC 21 Nov '17

21 Nov '17

#14493: Why is g++ necessary to compile GHC? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Simonpj noted after a system upgrade that GHC failed to build unless `g++` is installed. `libffi`'s `configure` otherwise failed with {{{ configure:13086: checking how to run the C++ preprocessor configure:13113: gcc -E conftest.cpp gcc: error trying to exec 'cc1plus': execvp: No such file or directory }}} Why is this necessary? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications
by GHC 20 Nov '17

20 Nov '17

#11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ data X a where MkX :: b -> Proxy a -> X a }}} According to the rules around specified vs. generalized variables around `TypeApplications`, the type of `MkX` should be {{{ MkX :: forall {k} (b :: *) (a :: k). b -> Proxy a -> X a }}} A few things to note: * The `k` isn't available for `TypeApplications` (that's why it's in braces), because it is not user-written. * The `b` is quantified before the `a`, because `b` comes before `a` in the user-written type signature for `MkX`. Both of these bullets are currently violated. GHCi reports `MkX`'s type as {{{ MkX :: forall k (a :: k) b. b -> Proxy a -> X a }}} It turns out that this is a hard to fix. The problem is that GHC expects data constructors to have their universal variables followed by their existential variables, always. And yet that's violated in the desired type for `MkX`. Furthermore, given the way that GHC deals with GADT return types ("rejigging", in technical parlance), it's inconvenient to get the specified/generalized distinction correct. Given time constraints, I'm afraid fixing this all won't make it for 8.0. Happily, there is are easy-to-articulate rules governing GHC's current (wrong) behavior. In a GADT-syntax data constructor: * All kind and type variables are considered specified and available for visible type application. * Universal variables always come first, in precisely the order they appear in the tycon. Note that universals that are constrained by a GADT return type are missing from the datacon. * Existential variables come next. Their order is determined by a user- written `forall`; or, if there is none, by taking the left-to-right order in the datacon's type and doing a stable topological sort. (This stable topological sort step is the same as for other user-written type signatures.) Despite the existence of these rules, it would still be better not to have special rules for GADT-syntax data constructors. This ticket is intended to capture that eventual goal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

Re: [GHC] #7258: Compiling DynFlags is jolly slow
by GHC 20 Nov '17

20 Nov '17

#7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "ghc-large-record-types.png" removed. Profile samples for W2.hs-style record types, comparing GHC performance for just the raw record type, derived Read, derived Show, and a hand- written getLine-based applicative record construction function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 101

[GHC] #14489: GHC panic from emacs haskell mode
by GHC 20 Nov '17

20 Nov '17

#14489: GHC panic from emacs haskell mode -------------------------------------+------------------------------------- Reporter: ggoetz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Hello, I encountered a ghc panic while going through one of the chapters from "Haskell Programming from first principles". The following error message is reported from flycheck checker from src/Main.hs in the attached files: {{{ Suspicious state from syntax checker haskell-stack-ghc: Flycheck checker haskell-stack-ghc returned non-zero exit code 1, but its output contained no errors: [1 of 2] Compiling Morse ( [some path]/haskell_programming/ch14/morse/src/Morse.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc- cache90097PyL/Morse.o ) [2 of 2] Compiling Main ( /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck90097c8R/Main.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc- cache90097PyL/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] convertLine_a2Ml :: t_a2Mk[tau:1] (CHoleCan: convertLine)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Try installing a more recent version of haskell-stack-ghc, and please open a bug report if the issue persists in the latest release. Thanks! }}} Stack upgrade reports "Skipping binary upgrade, you are already running the most recent version". I'm not entirely sure whether this should be reported or not (I can't say I know what I'm doing...), so I'm reporting it just in case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14491: Windows build with "--enable-distro-toolchain" fails with "make install"
by GHC 20 Nov '17

20 Nov '17

#14491: Windows build with "--enable-distro-toolchain" fails with "make install" -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: make | Operating System: Windows Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: 13792 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm building ghc (commit 606bbc310654fcf56fe068905bb1aca30d2f0a8a) under mingw64 shell. I ran the configure script with "--enable-distro- toolchain", and "make -j4" succeeds, yet "make install" yields the following error: {{{ ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final install /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin" "rm" -f "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh" echo "#!/bin/sh" >> /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh echo 'exec "$(dirname "$0")"/ghc --interactive "$@"' >> /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh chmod +x /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh cp /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii-8.3.20171120.sh chmod +x /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii-8.3.20171120.sh /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include" /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/." && /usr/bin/install -c -m 644 includes/./*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/./" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts" && /usr/bin/install -c -m 644 includes/rts/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/prof" && /usr/bin/install -c -m 644 includes/rts/prof/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/prof/" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/storage" && /usr/bin/install -c -m 644 includes/rts/storage/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/storage/" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/stg" && /usr/bin/install -c -m 644 includes/stg/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/stg/" && true /usr/bin/install -c -m 644 includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h includes/dist- derivedconstants/header/DerivedConstants.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/" /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include" /usr/bin/install -c -m 644 rts/dist/build/ffi.h rts/dist/build/ffitarget.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/" /usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib" "cp" driver/ghci/dist/build/tmp/ghci.exe driver/ghci/dist/build/tmp/ghci-8.3.20171120.exe /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin" for i in utils/hp2ps/dist-install/build/tmp/hp2ps.exe driver/ghci/dist/build/tmp/ghci.exe driver/ghci/dist/build/tmp/ghci-8.3.20171120.exe driver/ghc/dist/build/tmp/ghc-8.3.20171120.exe driver/haddock/dist/build/tmp/haddock-8.3.20171120.exe utils/hsc2hs/dist- install/build/tmp/hsc2hs.exe utils/ghc-pkg/dist-install/build/tmp/ghc- pkg.exe utils/hpc/dist-install/build/tmp/hpc.exe utils/runghc/dist- install/build/tmp/runghc.exe ghc/stage2/build/tmp/ghc-stage2.exe; do \ /usr/bin/install -c -m 755 $i "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin" ; \ done "cp" /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/runghc.exe /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/runhaskell.exe "rm" -f "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghc.exe" "mv" -f /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin /ghc-stage2.exe /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghc.exe make[1]: *** No rule to make target 'inplace/mingw', needed by 'install_mingw'. Stop. make: *** [Makefile:127: install] Error 2 }}} Is this a bug related to "--enable-distro-toolchain"? "inplace/mingw" rule should not exist here in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14491> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14486: Something is fishy in RTS's "max pause" GC statistic
by GHC 19 Nov '17

19 Nov '17

#14486: Something is fishy in RTS's "max pause" GC statistic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.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: -------------------------------------+------------------------------------- While looking into a GC issue, I found a peculiar inconsistency between the `+RTS -s` output and that from the eventlog. The `-s` output is, {{{ 13,756,939,024 bytes allocated in the heap 6,085,406,120 bytes copied during GC 182,001,080 bytes maximum residency (22 sample(s)) 753,160 bytes maximum slop 508 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 28674 colls, 28674 par 5.268s 2.949s 0.0001s 0.1016s Gen 1 22 colls, 21 par 0.004s 0.002s 0.0001s 0.0005s Parallel GC work balance: 79.36% (serial 0%, perfect 100%) TASKS: 9 (1 bound, 8 peak workers (8 total), using -N2) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.007s ( 0.017s elapsed) MUT time 4.353s ( 2.556s elapsed) GC time 5.272s ( 2.951s elapsed) EXIT time 0.004s ( 0.072s elapsed) Total time 9.635s ( 5.596s elapsed) Alloc rate 3,160,479,659 bytes per MUT second Productivity 45.2% of total user, 47.0% of total elapsed }}} Note the "Max pause" statistic: gen0 apparently pauses for four orders of magnitude more than gen1. This seems rather hard to believe. Moreover, if I open the eventlog from the same run in threadscope, I find, ||= Generation =||= Collections =||= Par collections =||= Elapsed time =||= Avg pause =||= Max pause =|| || GC Total || 27215 || 25518 || 2.83s || 0.0001s || 0.1016s || || Gen 0 || 25504 || 25504 || 1.55s || 0.0001s || 0.0012s || || Gen 1 || 15 || 14 || 0.99s || 0.0657s || 0.1016s || Hmmmmmmmmm... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 19 Nov '17

19 Nov '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9118: Can't eta-reduce representational coercions
by GHC 19 Nov '17

19 Nov '17

#9118: Can't eta-reduce representational coercions ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ import Data.Type.Coercion import Data.Coerce import Data.Proxy eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g eta2 _ = Coercion }}} I get {{{ Could not coerce from ‘f’ to ‘g’ because ‘f’ and ‘g’ are different types. arising from a use of ‘Coercion’ from the context (Coercible (f a) (g a)) bound by the type signature for eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g at /Users/rae/temp/Roles.hs:5:9-56 In the expression: Coercion In an equation for ‘eta2’: eta2 _ = Coercion }}} Unlike the case for #9116, this one is ''not'' expressible in Core. (At least, I don't see a way to do it.) So, to do this, we would have to update Core and then update the constraint solver. I ''do'' think this would be type safe. But, I also think it's reasonable to wait for someone with a real use case to shout before doing this. The only use case I have is to be able to do this: {{{ -- says that a's parameter is representational class Rep (a :: k1 -> k2) where co :: Coercible x y => Coercible (a x) (a x) instance Rep f => Rep (Compose f) where ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9