May 2017 - ghc-tickets

[GHC] #11654: User Guide: Generate command line options table from ghc-flags directives
by GHC 11 Oct '17

11 Oct '17

#11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.10.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: -------------------------------------+------------------------------------- Since the move to ReStructuredText and Sphinx we've generated the options summary tables and manpage with `utils/mkUserGuidePart`. The options are described in a set of Haskell modules which are a pain to edit and may easily fall out of date. It would be far better if we could generate these tables from the `.. ghc- flags` directives already present in the users guide. This will involve a bit of hacking with Sphinx, although it should be more than up to the task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10816: Fixity declaration for associated type rejected
by GHC 11 Oct '17

11 Oct '17

#10816: Fixity declaration for associated type rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeOperators, TypeFamilies #-} module Bug where class C a where type a # b infix 4 # }}} I get {{{ Bug.hs:7:11: ‘#’ is not a (visible) method of class ‘C’ }}} But it really should just assign a fixity to the type `#`. It works if the fixity declaration is outside of the class. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13652: Add integer division to GHC.TypeLits
by GHC 08 Oct '17

08 Oct '17

#13652: Add integer division to GHC.TypeLits -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) 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: -------------------------------------+------------------------------------- GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level: {{{#!hs quot rem div mod quotRem divMod }}} ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics
by GHC 04 Oct '17

04 Oct '17

#11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} module Pat (Vec2(Nil,(:>)), pattern (:>)) where newtype Vec2 a = Vec2 {unvec2 :: [a]} pattern Nil :: Vec2 a pattern Nil = Vec2 [] pattern (:>) x xs <- ((\ys -> (head $ unvec2 ys,Vec2 . tail $ unvec2 ys)) -> (x,xs)) where (:>) x xs = Vec2 (x:unvec2 xs) }}} and {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Main where import Pat (Vec2(..),pattern (:>)) }}} I get: {{{ $ ghci Main.hs GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Pat ( Pat.hs, interpreted ) Pat.hs:2:29: warning: [-Wduplicate-exports] ‘:>’ is exported by ‘(:>)’ and ‘Vec2(Nil, type (:>))’ [2 of 2] Compiling Main ( Main.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160411 for x86_64-unknown-linux): filterImports/combine (:>, :>, Nothing) (:>, Vec2{Vec2, :>, Nil}, Nothing) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Now, the warning about the duplicate export is of course correct. But the panic shouldn't happen when I try to import both the associated pattern synonym and the normal pattern synonym. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be better
by GHC 04 Oct '17

04 Oct '17

#12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be better -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | 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: -------------------------------------+------------------------------------- INLINE vs NOINLE vs <nothing> for this function https://github.com/LambdaHack/LambdaHack/blob/master/Game/LambdaHack/Client… produces distinct figures in all three cases. See https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that <nothing> should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be <nothing>, and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12747> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13561: Remove unsafe Chan combinators
by GHC 03 Oct '17

03 Oct '17

#13561: Remove unsafe Chan combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.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: #4154 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Namely `isEmptyChan` and `unGetChan`. See #4154. Let's delete them for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9725: Constraint deduction failure
by GHC 03 Oct '17

03 Oct '17

#9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I get a strange error message like this {{{ [1 of 1] Compiling Main ( 08-10.hs, interpreted ) 08-10.hs:254:33: Could not deduce (KnownLoc (ent par1 a)) arising from a use of ‘Hidden'’ from the context (List ConfFamily ts) bound by the type signature for locAware :: List ConfFamily ts => (forall (i :: k). KnownLoc (ent par i) => ConfFamily (Facility (ent par i)) ts) -> Con ConfFamily (On ent par) at 08-10.hs:251:13-160 or from (ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp)) bound by a pattern with constructor MonitorF :: forall (par :: Entity) (mp :: MonitorPoint). KnownLoc ('Monitor par mp) => String -> String -> Observer -> Bool -> Facility ('Monitor par mp), in an equation for ‘h’ at 08-10.hs:254:19-28 In the expression: Hidden' (d f) In an equation for ‘h’: h (Hide f@(MonitorF {})) = Hidden' (d f) In an equation for ‘locAware’: locAware descr = Abstr h where h :: (ent `On` par) -> ConfFamily (ent `On` par) ts h (Hide f@(MonitorF {})) = Hidden' (d f) d :: KnownLoc (ent par i) => Facility (ent par i) -> ConfFamily (Facility (ent par i)) ts d _ = descr Failed, modules loaded: none. }}} I have many language extensions active, such as, `DataKinds`, `ScopedTypeVariables`, etc. If somebody says this indeed looks like a bug, then I'll try to post a minimal reproduction case. ** My reasoning goes like this ** Here are the relevant facts that GHC figured out from a GADT pattern match: `(ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp))` From this I discover these equalities: {{{ ent === 'Monitor (*) par === par1 (**) a === mp (***) }}} Substituring `(*)`^-1^ and `(***)`^-1^ into the given `KnownLoc ('Monitor par1 mp)` results in the desired `KnownLoc (ent par1 a)` Looks like a bug, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12759: Latest Debian GCC breajs GHC
by GHC 02 Oct '17

02 Oct '17

#12759: Latest Debian GCC breajs GHC ----------------------------------------+-------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+-------------------------- Just got `gcc (Debian 6.2.0-9) 6.2.0 20161019` in a recent upgrade (Debian Testing) and now: {{{ > cat hello.hs main :: IO () main = putStrLn "Hello" > ghc hello.hs -o hello [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... /usr/bin/ld: hello.o: relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' \ can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/ghc-8.0/lib/base-4.9.0.0/libHSbase-4.9.0.0.a(Base__166.o): \ relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not be used when \ making a shared object; recompile with -fPIC .... }}} The previous version of gcc in Debian Testing (gcc (Debian 6.2.0-6) 6.2.0 20161010) is fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #9198: large performance regression in type checker speed in 7.8
by GHC 02 Oct '17

02 Oct '17

#9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- it was recently demonstrated on the haskell-cafe mailing list that the following code takes measurably longer to type check in GHC 7.8.2 than in GHC 7.6. http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html the program example is as follows {{{ begin cont = cont (return ()) a m =cont (m >> putstrn "a") end m = m main = begin a a a a a a a a a a a a a a a a a end }}} takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () each additional a doubles the time to type check the program {{{ main = begin a a a a a a a a a a a a a a a a a a a a a a a a end }}} takes longer than I have the patience to wait :) (so more than 5 seconds) the author of the email notes that a related program {{{ main = id id id id id id id id id id id id id id id id id id id id id id (return ()) }}} has the exponential complexity in both 7.8.2 and 7.6.2 This It could very well be that some of the type checker changes between 7.8 and 7.6 enlarged the space of programs that trip up exponential worst case behavior, but one way or another understanding *why* this happened -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13397: Optimise calls to tagToEnum#
by GHC 02 Oct '17

02 Oct '17

#13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- Ever since we started using `Int#` to represent booleans unboxed (see [wiki:PrimBool]) we have had lots of code looking like {{{ case tagToEnum# (a ># b) of False -> e1 True -> e2 }}} It would be better (less code to optimise, more straightforward, more direct) to optimise this to {{{ case a ># b of DEFAULT -> e1 1# -> e2 }}} Happily, we already have a nice spot to do so: the `caseRules` function in `SimplUtils`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13397> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15