- ghc-tickets - Haskell.org

[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 22 Sep '17

22 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

[GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually
by GHC 21 Sep '17

21 Sep '17

#14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test case is in this repo on the `inlining-issue` branch: https://github.com/harendra-kumar/ghc-perf/tree/inlining-issue. Performance with manually inlining a function is more than 10% faster compared to factoring out code and using INLINE pragma. `stack bench` for compiler inlined code {{{ time 46.71 ms (45.53 ms .. 47.79 ms) }}} `stack bench --flag ghc-perf:manual` for manually inlined code {{{ time 39.46 ms (38.92 ms .. 39.94 ms) }}} Here is the relevant code: {{{#!hs {-# INLINE bindWith #-} bindWith :: (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a `k` (bindWith k r f) in m Nothing stp yield instance Monad m => Monad (AsyncT m) where return a = AsyncT $ \ctx _ yld -> yld a ctx Nothing #ifdef MANUAL_INLINE AsyncT m >>= f = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a <> (r >>= f) in m Nothing stp yield #else (>>=) = bindWith (<>) #endif }}} I have seen this many times. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14260: Type family in instance signature confuses GHC
by GHC 21 Sep '17

21 Sep '17

#14260: Type family in instance signature confuses GHC -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This works: {{{#!hs class F a where type T a u :: T a -> a -> a newtype W a = W a instance F (W a) where type T (W a) = T a u = undefined instance F () where type T () = T (W ()) u _ = undefined }}} Remove one argument to `u` and you get {{{#!hs • Reduction stack overflow; size = 201 When simplifying the following type: T (W ()) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: undefined In an equation for ‘u’: u = undefined In the instance declaration for ‘F ()’ }}} It is also not accepted to {{{#!hs u :: T (W ()) -> () -> () u _ = id @() }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?)
by GHC 21 Sep '17

21 Sep '17

#14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First, let me explain the context. By defuault GHC specialises very few functions and the programmer is expected to enumerate additional functions to specialise (e.g., with INLINABLE). This is problematic if the functions are defined in libraries, not in the user code. Also, in some kinds of code it leads to INLINABLE on every functions (because missing even just one breaks the chain). The problems are described in other tickets. With `-fspecialise-aggressively` and `-fexpose-all-unfoldings`, the default is reversed. Everything (even functions from libraries, as long as they have unfoldings available) is specialized and the user only needs to enumerate exceptions. Unfortunately, he can't. I think (in particular from experiments with `-Wall-missed- specialisations`), in the presence of `-fexpose-all-unfoldings`, the `-fspecialise-aggressively` option happily specialises functions marked `NOINLINE` (and so with `Inline:,` in the .hi file). Consequently, the user has no way to be selective wrt specialisation when using the specialize-often default. If we want to gradually disentangle INLINE and SPECIALIZE (e.g., rename INLINABLE to SPECIALISABLE), perhaps the pragma to use should be NOSPECIALISABLE. Perhaps it also makes sense to leave the current functionality, for experimenting with whole modules, but I'd rename it to `-fforce-specialise-aggressively`, because it overrides the obvious user intent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5