August 2017 - ghc-tickets

[GHC] #14076: cons operator for list give weird output
by GHC 03 Aug '17

03 Aug '17

#14076: cons operator for list give weird output -------------------------------------+------------------------------------- Reporter: AshHash | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: cons(:) | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- on typing the following command in ghci\\ :t 1:2\\ I get the output\\ (Num [a], Num a) => [a]\\ While running the same on char like follows, gives me an error:\\ :t 'a':'b' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14053: Runtime linker failed due to a duplicate symbol definition
by GHC 03 Aug '17

03 Aug '17

#14053: Runtime linker failed due to a duplicate symbol definition -------------------------------------+------------------------------------- Reporter: | Owner: (none) SwiftsNamesake | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: linker, | Operating System: Unknown/Multiple windows | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Preprocessing library Pixels-0.1.0.0... [1 of 9] Compiling Pixels.Walker ( src\Pixels\Walker.hs, .stack- work\dist\ca59d0ab\build\Pixels\Walker.o ) [2 of 9] Compiling Pixels.Types ( src\Pixels\Types.hs, .stack- work\dist\ca59d0ab\build\Pixels\Types.o ) GHC runtime linker: fatal error: I found a duplicate definition for symbol runInteractiveProcess whilst processing object file C:\Users\Jonatan\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\process-1.4.3.0\HSprocess-1.4.3.0.o The symbol was previously defined in C:\sr\snapshots\55a68d16\lib\x86_64-windows- ghc-8.0.2\process-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5\HSprocess-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Jonatan\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.0.2\\lib\\process-1.4.3.0\\HSprocess-1.4.3.0.o": failed CallStack (from HasCallStack): error, called at libraries\ghci\GHCi\ObjLink.hs:97:21 in ghci-8.0.2:GHCi.ObjLink Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} OS: Windows 10 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13529: eventlog to report more information about stopping threads because of FFI calls
by GHC 02 Aug '17

02 Aug '17

#13529: eventlog to report more information about stopping threads because of FFI calls -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently eventlog file doesn't contain more information about FFI than: "stopping thread ### (making a foreign call)" It would be very-very useful if we know what actual foreign calls are made. For example: "stopping thread ### (making a foreign call to function YYYY) So we could see which function and how much time is spent on that call. If creation of threads because of in-bound foreign calls (callbacks) have which callbacks are created for it will be very useful, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13689: Data.Either doesn't export INLINABLE short functions like "rights"
by GHC 02 Aug '17

02 Aug '17

#13689: Data.Either doesn't export INLINABLE short functions like "rights" -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently if I use Data.Either's simple functions like "rights", "isLeft", etc. In Core/Cmm with -O2 I see that they are called like external functions and not inlined. This is because they are not marked as INLINABLE in the library itself. It'll be great if such functions in base are marked as INLINABLE so optimizator/inliner to generate more efficient code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #13980: Broken ghc-flag links in the users guide
by GHC 02 Aug '17

02 Aug '17

#13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- I'm working on cleaning up the users guide, and I have come across an issue with referencing ghc-flags. Essentially, it has to with flags that take arguments. You can see a couple examples if you go to the flag reference here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html #redirecting-output The top flags all have valid links, but the code to generate them is doing it slightly wrong. Let's consider `-o ⟨filename⟩` for instance. There needs to be a specific reference name for this flag. This name serves a couple purposes. First, it forms the end of the url (i.e. .../separate_compilation.html#ghc-flag--o). Second, the form of cross- references to it (i.e. {{{:ghc-flag:`-o`}}}). There are two options: Option 1 (The current system): We exclude the arguments from the reference name of the flag. So {{{:ghc- flag:`-o`}}} is a valid reference that gets rendered as __-o__. The main issue with this system is loss of information. If someone wanted to include the flags in the link, they would have to do {{{:ghc-flag:`-o ⟨filename⟩ <-o>`}}}, which would render as __-o ⟨filename⟩__ but link to the same place as __-o__. This also leads to possibly different choices for the argument name. In fact, the definition has `⟨file⟩` but the reference table has `⟨filename⟩`. Option 2: We include the arguments in the reference name. So to make the reference, one would have to match the definition exactly: {{{:ghc-flag:`-o ⟨file⟩`}}} which would be rendered as __-o ⟨file⟩__, and {{{:ghc-flag:`-o ⟨filename⟩`}}} would not be a valid reference. This solves the loss of information issue from option 1, but does require the person documenting to check for the exact argument wording. I would argue for the second option as it is more consistent, but either is workable. Also note that the current parser automatically converts < (less than) into ⟨, so dealing with special characters is very easy. And these issues also apply to flags that use '='. I thought it best to ask before I converted everything to one way of dealing with these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue
by GHC 02 Aug '17

02 Aug '17

#12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I try to build language-lua as found on Hackage with GHC 8.0.2-rc2 I get the following error. This package works with 8.0.1. I'm using the latest release of cabal-install/Cabal and alex-3.2.1 {{{#!hs src/Language/Lua/Annotated/Lexer.x:149:14: error: • Can't find interface-file declaration for variable AlexTools.runA Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP In the expression: case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } In a case alternative: AlexToken x_a28iK x_a28iL x_a28iM -> case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS
by GHC 02 Aug '17

02 Aug '17

#13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: hs-boot | 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 is a follow up ticket for #13803, since I wanted to fix the immediate bug in #13803 without having to deal with the more complicated case here: {{{ -- F.hs {-# LANGUAGE TypeFamilies #-} module F where type family F a :: * -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A import F type instance F T = Int -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import {-# SOURCE #-} A import F type instance F T = Bool -- A.hs module A where import B import C }}} From what I wrote: right now, we decide to defer a type family consistency check if the family was recursively defined. If the RHS refers to a recursively defined type, there's no problem: we don't need to look at it for consistency checking. But if the LHS is recursively defined, as is in this example, we DO need to defer the check. But it's a bit irritating to figure out whether or not there's actually a reference to a recursively defined type in the LHS, since this involves traversing the LHS types, and if we're not careful we'll end up pulling in the TyThing anyway. There are two other possibilities: (1) always defer checking instances which are defined inside the recursive look (by looking at the Name of the axiom), or (2) annotating IfaceAxiom with the set of boot types its LHS refers to, for easy checking. Not entirely sure what the best action is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary
by GHC 02 Aug '17

02 Aug '17

#14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally spun off from #12369.) The documentation for data families currently [http://git.haskell.org/ghc.git/blob/791947db6db32ef7d4772a821a0823e558e3c05… claims]: {{{ - Data families have been generalised a bit: a data family declaration can now end with a kind variable ``k`` instead of ``Type``. Additionally, data/newtype instance no longer need to list all the patterns of the family if they don't wish to; this is quite like how regular datatypes with a kind signature can omit some type variables. }}} Moreover, the commit which added this (4239238306e911803bf61fdda3ad356fd0b42e05) cites this particular example: {{{#!hs data family Sing (a :: k) data instance Sing :: Bool -> Type where ... }}} However, in practice, this does //not// typecheck on GHC HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind data family Sing (a :: k) data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170725: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:8:1: error: • Number of parameters must match family declaration; expected 0 • In the data instance declaration for ‘Sing’ | 8 | data instance Sing :: Bool -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #14077: libmingw32.a: Not x86_64 PEi386
by GHC 02 Aug '17

02 Aug '17

#14077: libmingw32.a: Not x86_64 PEi386 -------------------------------------+------------------------------------- Reporter: YoYoYonnY | 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: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After a fresh installation of the Haskell Platform (on Windows), I received the following error: {{{ >ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc.exe: D:/MinGW/bin/../lib/libmingw32.a: Not x86_64 PEi386 ghc.exe: internal error: loadArchive: error whilst reading `D:/MinGW/bin/../lib/libmingw32.a' (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. }}} Invoking GHC will instead error with a bunch of GCC error messages related to standard C library headers (multiple definitions of {{{time_t}}}, etc.). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes
by GHC 02 Aug '17

02 Aug '17

#13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4028 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something's funny with `Data.Data`. In particular, what instance do you expect when you write this? {{{#!hs data T phantom = T deriving Data }}} You might expect: {{{#!hs instance Typeable phantom => Data (T phantom) where ... }}} And indeed, it is possible to define a `Data` instance like this. But in practice, GHC actually derives this instance: {{{#!hs instance Data phantom => Data (T phantom) where ... dataCast1 f = gcast1 f }}} The reason is because GHC has special cases for when it derives `Data` instances for datatypes of kind `* -> *` or `* -> * -> *`. These special cases cause the derived `Data` instances to insert definitions for `dataCast1` or `dataCast2`, respectively, and their implementations (`gcast1` or `gcast2`, respectively) require the stronger instance context. See #4028 for a longer discussion about this. Things get far less predictable when you throw in `PolyKinds`, however. If you try this instead: {{{#!hs data T (phantom :: k) = T deriving Data }}} Then you do //not// get `instance Data phantom => Data (T phantom)` as above. Instead, you get this: {{{#!hs instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where ... -- No implementation for dataCast1 }}} As it turns out, GHC's special-casing for deriving `Data` is not privy to datatypes of kind `k -> *` or `k1 -> k2 -> *`, just `* -> *` and `* -> * -> *`. This is all a bit disconcerting because if you look at `Data.Data`, there are many instances of the flavor: {{{#!hs deriving instance Data (p :: *) => Data (U1 p) -- U1 :: k -> * }}} This makes sense in a pre-`PolyKinds` world, but really, the most general type for this `Data` instance would be: {{{#!hs deriving instance (Typeable k, Typeable (p :: k)) => Data (U1 p) }}} Even worse, choosing the less polymorphic instance `Data (p :: *) => Data (U1 p)` via `StandaloneDeriving` doesn't even cause GHC to emit a definition for `dataCast1`—it just restricts the kind with no benefit! This whole situation doesn't sit well with me, especially since as we add more poly-kinded `Data` instances to `Data.Data`, we have to ask ourselves each time what the "right" `Data` instance is. It would be great if we could answer these questions: 1. Should we expand the special-casing for datatypes of kind `k -> *` or `k1 -> k2 -> *`? Or do `dataCast1` and `dataCast2` even make sense for poly-kinded datatypes? 2. Is there a way to modify `DeriveDataTypeable` such that emitting definitions for `dataCast1` and `dataCast2` don't require us to default some kind variables to `*`? Perhaps `TypeInType` could help us here somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4