January 2017 - ghc-tickets

[GHC] #12750: hGetContents leads to late/silent failures
by GHC 21 Jan '17

21 Jan '17

#12750: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: | Owner: massimo.zaniboni | Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: https://github.com/massimo- | zaniboni/ghc_lazy_file_content_error| Blocking: | Related Tickets: #9236 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the same problem described in the closed ticket #9236 This is a test-case https://github.com/massimo- zaniboni/ghc_lazy_file_content_error I tried with ghc 7.10.3 and 8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 21 Jan '17

21 Jan '17

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: T7102a, T7102 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2994 Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Perhaps the error message for the instance overlap could mention (if in GHCi) that you can get around it by redeclaring the type family. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10515: ghc: panic: tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’
by GHC 20 Jan '17

20 Jan '17

#10515: ghc: panic: tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’ -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Has anyone seen something like this? {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150519 for x86_64-unknown-linux): tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy
by GHC 20 Jan '17

20 Jan '17

#12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- Oddly this only happens on our build server, not on my local machine. On compilation, I get: {{{ [187 of 273] Compiling Query.Order ( Query/Order.hs, dist/build/Query/Order.o ) Query/Order.hs:340:1: warning: [-Wredundant-constraints] • Redundant constraint: MonadBaseControl IO m • In the type signature for: updateOrdersSuccess :: (MonadBaseControl IO m, MonadTransaction m) => m () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): piResultTy Maybe Int64 a1_a4WiL Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The configuration parameters are: {{{ configureFlags: --verbose --prefix=/nix/store /qxfjd5jxr593dn43i3659s86d0rdllyv-circuithub-api-0.0.4 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc --package-db=/tmp/nix-build-circuithub-api-0.0.4.drv-0/package.conf.d --ghc-option=-j1 --disable-split-objs --disable-library-profiling --disable-profiling --disable-shared --enable-library-vanilla --disable- executable-dynamic --disable-tests }}} I've attached Query/Order.hs, but you won't be able to compile it stand- alone. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13129: Warn about home module, not listed in commang line
by GHC 20 Jan '17

20 Jan '17

#13129: Warn about home module, not listed in commang line -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- It is an attempt to fix this cabal issue: https://github.com/haskell/cabal/pull/1455 Basically, when user fails to list all modules in `exposed-modules` or `other-modules`, cabal produces broken package. The idea of the fix is to teach GHC to warn about home modules (not from an other package), that are not explicitly listed in command line. Option name `-Wmissing-home-modules` is a subject for bikeshedding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13099: recompilation can fail to recheck type family instance consistency
by GHC 20 Jan '17

20 Jan '17

#13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Suppose I have two modules `I1` and `I2` that define instances for the same type family and I have a module `M` consisting solely of {{{#!hs module M where import I1 import I2 }}} When GHC compiles `M` it checks that the type family instances of `I1` are consistent with those from `I2`. Then it writes out `M.hi` which is treated as a certificate that the type family instances of `I1` and `I2` are compatible: {{{ How do we know which pairs of modules have already been checked? Any pair of modules where both modules occur in the `HscTypes.dep_finsts' set (of the `HscTypes.Dependencies') of one of our directly imported modules must have already been checked. Everything else, we check now. (So that we can be certain that the modules in our `HscTypes.dep_finsts' are consistent.) }}} That means in particular that another module that imports `M` doesn't have to check family instance consistency between `I1` and `I2`. (Imagine `I1` and `I2` are two internal modules of a library and `M` is its top-level interface that just re-exports things.) Now suppose I edit `I2` in a way that makes its type family instances no longer consistent with those of `I1`, then recompile `I2` and then `M` in one-shot mode. Since `M` did not really use anything from `I2`, ghc concludes that recompilation of `M` is not required. But now the `M.hi` file is incorrect as a certificate that `I1` and `I2` have consistent instances and a consumer of `M` would be able to see the inconsistency even if it uses parts of `I1` and `I2` that changed. Two possible ways to address this: 1. Since `M.hi` represents a certificate of consistency between `I1` and `I2`, `M` should be considered to "use" the family instances so that it is recompiled when the instances change. 2. When determining which pairs of modules we don't need to check for consistency in FamInst, we take some interface hash into account to make sure that the versions of (in this case) `I1` and `I2` that were checked for consistency when we compiled `M` are the same ones that we are importing in our client of `M`. I think we might want both of these, but especially the second one. This might ideally involve adding a "type family instances hash" to the interface file if it doesn't already exist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12162: Concatenation of type level symbols missing
by GHC 20 Jan '17

20 Jan '17

#12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: 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: -------------------------------------+------------------------------------- Type level string literals (of kind Symbol), should have a concatenation operation. It's very useful, e.g., in the library for strongly typed relations that we have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13156: CSE missing an easy case
by GHC 20 Jan '17

20 Jan '17

#13156: CSE missing an easy case -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Consider this Core: {{{ case f @Int of { r1 -> case f @Int of { r2 -> ... }}} There is an easy common sub-expression to be had here, which would allow to eliminate a case expression, but CSE didn't spot it in GHC 8. Easy to fix. Here's an example that shows it {{{ module Bug where f g x = let r :: [a] -> [a] r = case g x of True -> reverse . reverse False -> reverse in r `seq` r `seq` True }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13155: exprIsExpandable bug
by GHC 20 Jan '17

20 Jan '17

#13155: exprIsExpandable bug -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- Consider this program, derived from T5623 (c.f. #5623) {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -funfolding-use-threshold=10 #-} module T5623 where import GHC.Ptr import GHC.Prim import GHC.Exts foo :: Ptr Float -> State# RealWorld -> (# State# RealWorld, Float #) -- foo p = liftM2 (+) (peekElemOff q 0) (peekElemOff q 1) foo p s = case q :: Ptr Float of { Ptr a1 -> case readFloatOffAddr# a1 0# s of { (# s1, f1 #) -> case q :: Ptr Float of { Ptr a2 -> case readFloatOffAddr# a2 1# s of { (# s2, f2 #) -> (# s2, F# (plusFloat# f1 f2) #) }}}} where q :: Ptr a -- Polymorphic q = p `plusPtr` 4 }}} The `-funfolding-use-threshold=10` is important because it makes the worker/wrapper pass do a w/w split for `foo`. (Otherwise it's too small for w/w.) The optimised core looks like {{{ foo = \ (w_s2TO :: Ptr Float) (w1_s2TP :: State# RealWorld) -> case w_s2TO of { Ptr ww1_s2TS -> case readFloatOffAddr# @ RealWorld (plusAddr# ww1_s2TS 4#) 0# w1_s2TP of { (# ipv_s2ST, ipv1_s2SU #) -> case readFloatOffAddr# @ RealWorld (plusAddr# ww1_s2TS 4#) 1# w1_s2TP of { (# ipv2_s2SY, ipv3_s2SZ #) -> (# ipv2_s2SY, GHC.Types.F# (plusFloat# ipv1_s2SU ipv3_s2SZ) #) } } } }}} Yikes! Look at that duplicated `plusAddr#`! It turned out to be a hard-to-trigger bug in `exprIsExpandable`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 20 Jan '17

20 Jan '17

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: T7102a, T7102 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2994 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * testcase: => T7102a, T7102 * differential: => Phab:D2994 Comment: There are actually two issues in this ticket. * The original issue, that you can replace type family instances in ghci as in comment:1. There was special logic to allow this (copied from the case of class instances), so fixing it was just deleting code (that I was going to have to change anyways, for another issue). I added test `T7102a` for this one. * The issue in comment:7 is different, and doesn't rely on the two instances having the same LHS. It's apparently not that ghci is replacing one instance with the other one, but rather that it never checks that the two instances are consistent with each other. So we need an additional consistency check somewhere. I haven't fixed this yet, but I added a expect_broken test `T7102` for it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0