September 2017 - ghc-tickets

[GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable
by GHC 25 Sep '17

25 Sep '17

#14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program, {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Test where import GHC.Exts import Data.Kind data TypeRep (a :: k) where Con :: TypeRep (a :: k) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) pattern Fun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern Fun arg res <- TrFun arg res where Fun arg res = undefined data Dynamic where Dynamic :: forall a. TypeRep a -> a -> Dynamic -- Removing this allows compilation to proceed {-# COMPLETE Con #-} dynApply :: Dynamic -> Dynamic -> Maybe Dynamic -- Changing Fun to TrFun allows compilation to proceed dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = undefined dynApply _ _ = Nothing }}} As written the program fails with, {{{ test.hs:34:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘dynApply’: dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = ... | 34 | dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = undefined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This can be worked around by doing one of the following, 1. Removing the `COMPLETE` pragma 2. Changing the use of the `Fun` pattern synonym into a use of the `TrFun` constructor. Something is quite wrong here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14188: On windows, trace prints out lines without proper line endings
by GHC 25 Sep '17

25 Sep '17

#14188: On windows, trace prints out lines without proper line endings -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Try this on Windows {{{ module Foo where f x = x }}} and now {{{ ghc -c -dverbose-core2core Foo.hs 2> foo }}} Now edit `foo`. You'll see that * Some lines, produced by monadic IO, I think, have CRLF endings (`^M^J`). * But others, produced by `pprTrace` (actually `Simplify.hs` line 220, only have a LF ending (`^J`). The inconsistent line endings confuses emacs, which displays `^M` at the end of all the CRLF lines (ie most of them). This is Jolly Annoying. John Wiegley has made me a special SPJ-only emacs mimor mode that suppresses the annoying `^M` stuff, but that seems like extreme measures. Question: why doesn't `pprTrace` properly terminate its lines? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel
by GHC 24 Sep '17

24 Sep '17

#14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- How to repdoruce on amd64: {{{ $ ./configure --enable-unregisterised $ make }}} Build failure: {{{ rts_dist_HC rts/dist/build/PrimOps.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): pprCLbl AsmTempLabel }}} Normally UNREG backend has no asm labels. changeset:8b007abbeb3045900a11529d907a835080129176 looks vaguely relevant as it adds AsmTempLabel in one place. But I did not look in detail yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14269: ghc: internal error: PAP object entered!
by GHC 22 Sep '17

22 Sep '17

#14269: ghc: internal error: PAP object entered! -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ > ghc hplay.hs -o hplay.exe [1 of 1] Compiling Main ( hplay.hs, hplay.o ) ghc: internal error: PAP object entered! (GHC version 8.0.2 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. }}} Test file: {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE QuasiQuotes #-} module Main where import qualified Language.C.Inline as C main :: IO () main = [C.block||] }}} Using inline-c-0.6.0.5 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14269> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13608: Expose the type of quasiquotes
by GHC 22 Sep '17

22 Sep '17

#13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: QuasiQuotes | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12778 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It happens with inline-java that {{{ [java| 0.0 |] }}} produces a static method in java {{{ Object fresh_name() { return 0.0; } }}} where {{{ double fresh_name() { return 0.0; } }}} would be preferred. This is better because the user would get an error if the expression does not match the expected result type. Examining the context in which the quasiquote is used would allow to build the later variant. However, GHC provides no way to grab the type that it expects of the quasiquote. The quasiquote desugars as follows: {{{ [java| 0.0 |] ====> $(parseExp java " 0.0 ") }}} We have experimented with a patch that desugars instead like {{{ [java| 0.0 |] ====> let __ghc_qq_<loc_hash> = $(parseExp java " 0.0 ") in __ghc_qq_<loc_hash> }}} The quasiquoter can learn then of the expected type by doing: {{{ do qqName <- getCurrentQuasiQuoteName addModFinalizer $ reify qqName >>= ... where getCurrentQuasiQuoteName :: Q Name getCurrentQuasiQuoteName = do loc <- TH.location return $ mkName $ "__ghc_qq_" ++ hash loc }}} Where `getCurrentQuasiQuoteName` can be provided in `Language.Haskell.TH.Quote`. This addresses the same concern that I initially intended to solve with the more complex proposal in #12778. I hope to submit a patch this week, but it would be useful if people want to provide some feedback about the proposal meanwhile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #14267: CLong is not what it seems on Windows
by GHC 21 Sep '17

21 Sep '17

#14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: #14262 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://hackage.haskell.org/package/base-4.10.0.0/docs/Foreign-C-Types.html… The docs of CLong] say {{{ newtype CLong = CLong Int64 Haskell type representing the C long type. }}} But on 64-bit Windows, [https://stackoverflow.com/questions/384502/what- is-the-bit-size-of-long-on-64-bit-windows#384672 long is 32 bits]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13847: record construction accepts local unqualified name instead of qualified imported name
by GHC 21 Sep '17

21 Sep '17

#13847: record construction accepts local unqualified name instead of qualified imported name -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{ module A where data A = A { foo :: () } deriving Show }}} the following code is accepted {{{ module Main where import qualified A foo = "foo" main = print $ A.A { foo = () } }}} albeit with a warning {{{ B.hs:4:16: warning: [-Wmissing-fields] • Fields of ‘A.A’ not initialised: foo }}} Indeed the `foo = ()` is type-checked as if it were `A.foo = ()` but the `foo` field is actually not assigned. Evaluation gives {{{ *Main> main A {foo = *** Exception: B.hs:4:16-31: Missing field in record construction foo }}} The code should be rejected outright? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc
by GHC 21 Sep '17

21 Sep '17

#13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In Haskell, 1. The scope of definitions can be controled. 2. The same name can be used to define both a function and a field of record. 3. The user can use that name in record pattern matching when only the function is within scope. For example {{{ FuncId{ name = nm } }}} resulting in the following bug {{{ [38 of 39] Compiling TxsUtils ( src\TxsUtils.hs, .stack- work\dist\1f7101f2\build\Txs Utils.o ) ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): translateConPatVec: lookup Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #14128: Possible bug in Renamer when dealing with orphans
by GHC 21 Sep '17

21 Sep '17

#14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In a [https://github.com/shayan-najd/GrowableGHC branch] of GHC with [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow Growable ASTs], the code compiles with `devel2` configuration, but fails with `./validate`. It passes all the test cases, except two that already fail in HEAD (see [https://ghc.haskell.org/trac/ghc/ticket/14126 #14126]). Especifically, the compiler returns the following error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170806 for x86_64-unknown-linux): ASSERT failed! HsPat [GHC.Base, GHC.Float, Data.Binary.Generic, Data.ByteString.Builder, HsBinds, HsDoc, HsExpr, HsLit, HsPat, HsTypes, PprCore, GHC.LanguageExtensions, Data.Time.Calendar.Gregorian, Data.Time.Format.Parse, Data.Time.LocalTime.Internal.LocalTime, Data.Time.LocalTime.Internal.ZonedTime] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/rename/RnNames.hs:364:99 in ghc:RnNames Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/rename/RnNames.hs:364:99 in ghc:RnNames Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I suspect (as hinted above) it has to do with a bug in the renamer when dealing with orphan instances (and probably in conjunction with boot files). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction
by GHC 21 Sep '17

21 Sep '17

#13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a file: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Bug (Boolean(F, TooGoodToBeTrue), catchAll) where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 -- catchAll TooGoodToBeTrue = 1 }}} If you compile this with `-Wall`, the warning will warn about `T`, not `TooGoodToBeTrue` (the other conlike in the `COMPLETE` set): {{{ $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp -Wall Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘catchAll’: Patterns not matched: T | 15 | catchAll F = 0 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Perhaps this isn't so bad, since it's intra-module. But the problem persists even across modules: {{{#!hs module Foo where import Bug catchAll2 :: Boolean -> Int catchAll2 F = 0 -- catchAll2 TooGoodToBeTrue = 1 }}} {{{ $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp -c Bug.hs $ /opt/ghc/8.2.1/bin/ghc -fforce-recomp -c -Wall Foo.hs Foo.hs:6:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘catchAll2’: Patterns not matched: Bug.T | 6 | catchAll2 F = 0 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This one is really bad, since it's warning about `Bug.T`, which should be hidden! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4