November 2015 - ghc-tickets

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 01 Nov '15

01 Nov '15

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ghorn): * cc: gregmainland@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11035: Add implicit call-stacks to partial functions in base
by GHC 01 Nov '15

01 Nov '15

#11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From https://www.reddit.com/r/haskell/comments/3qpefo/a_very_unfortunate_error_m… {{{ ghci> minimumBy compare [] *** Exception: Prelude.foldr1: empty list CallStack: error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List }}} This is not a very useful call-stack. It tells us that error was called in GHC.List, and if we happen to have the source we can even see where it was called. https://github.com/ghc/ghc/blob/master/libraries/base/GHC/List.hs#L999 But that's '''still''' not very helpful because: 1. It points us to some generic `errorEmptyList` function. This function always diverges, so by our current rule it ought to get a CallStack constraint. Oops! 2. Even if we add the CallStack to `errorEmptyList`, the next culprit will (presumably) be `foldr1`, where the stack ends again. `foldr1` is partial, but it doesn't '''always''' diverge, so our current rule would say it shouldn't get a CallStack. This is quite unfortunate because the CallStack will point the finger at `foldr1`, but the error message itself '''already does that'''. So we haven't really gained anything by using the CallStack-aware `error` in base. What we really want to know is where `foldr1` was called, which just so happens to be `minimumBy` itself! Ben Gamari pinged me earlier today on IRC with a similar instance in GHC.Arr. ---- So, I think we should '''consider''' expanding the use of CallStacks in base by one level, to partial functions. By "partial" I specifically mean functions that directly call `error` or one of its wrappers (like `errorEmptyList`). That means that {{{#!haskell head [] = error "bad" head (x:xs) = x }}} would get a CallStack, but {{{#!haskell minimumBy cmp = foldr1 min' where min' x y = case cmp x y of GT -> y _ -> x }}} would '''not''', even though `minimumBy` is also partial in the traditional sense. I recall three arguments against broader use of CallStacks: 1. '''Performance concerns''': CallStacks exist at runtime in the form of an extra parameter to each CallStack-aware function. This is a valid concern and we should certainly do some benchmarking to see what the effects are. 2. '''Readability concerns''': Adding CallStacks will clutter otherwise simple type signatures, e.g. {{{#!haskell head :: [a] -> a head :: (?callStack :: CallStack) => [a] -> a }}} Also a valid concern, especially considering that base functions are the first novices will encounter. But I think we can mitigate this one in two steps. (1) The `:type` command in ghci already suppresses the CallStacks (because it happens to invoke the constraint solver), but `:info` shows them. I think this is fine as is. (2) If haddock shows CallStacks (I'm not sure if it does), we could patch haddock to render them differently. For example, instead of rendering the full type, just render {{{ head :: [a] -> a }}} with a badge that indicates that `head` is location-aware. That would reduce the cognitive overhead of the larger type signature, while retaining the important data. 3. '''Slippery slope''': Where do we draw the line? Why should `head` get a CallStack but not `minimumBy`? I don't have a good answer to this one yet, apart from a suspicion that my proposal will get us a closer to an 80/20 balance. I'm sure this would need to go through the Core Libraries Committee, but I'd also like feedback from fellow GHC devs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11021: Document best practices for bringing up Sphinx on Windows
by GHC 01 Nov '15

01 Nov '15

#11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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: -------------------------------------+------------------------------------- The Sphinx documentation tool that we now use to generate the users guide is unfortunately a bit tricky to get working on Windows. See, for instance, https://mail.haskell.org/pipermail/ghc- devs/2015-October/010199.html We need to improve this situation or at very least document how users can build documentation on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two
by GHC 01 Nov '15

01 Nov '15

#11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: T3294 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed that D757 caused max_bytes_allocated to go from 45MBytes to 96MBytes while updating the testsuite. This may be expected but I want to ensure I look into this since the test defines only one type (albeit with many fields) and a `Show` instance so we wouldn't necessarily expect this test to regress by this amount. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11017: ApiAnnotations: BooleanFormula is not properly Located
by GHC 01 Nov '15

01 Nov '15

#11017: ApiAnnotations: BooleanFormula is not properly Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment `BooleanFormula` is defined as {{{#!hs data BooleanFormula a = Var a | And [BooleanFormula a] | Or [BooleanFormula a] deriving (Eq, Data, Typeable, Functor, Foldable, Traversable) }}} An API Annotation can only be attached to an item of the form `Located a`. Replace this with a properly `Located` version, and attach the appropriate API Annotations to it -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11043: Bump `ghc-prim` to 0.5.0.0
by GHC 01 Nov '15

01 Nov '15

#11043: Bump `ghc-prim` to 0.5.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: | Version: 7.11 libraries/base | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes)
by GHC 01 Nov '15

01 Nov '15

#10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: #10682 Differential Revisions: | -------------------------------------+------------------------------------- Attempting to build GHC on an x86_64 Linux machine fails for me: {{{ $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" dll-split: out of memory (requested 1099512676352 bytes) make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10917: Provide a utility to check API Annotations
by GHC 01 Nov '15

01 Nov '15

#10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- At the moment it is difficult for GHC developers to know if they have broken the API Annotations. Provide a utility that can be used as a test to show up errors in the API Annotations. This is to be based on the current tests for ghc-api/annotations which can parse a file using the just-built GHC API, and check that no annotations are disconnected from the ParsedSource in the output. In addition, it should be able to dump the annotations to a file, so a new feature developer can check that all changes to the parser do provide annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9