May 2018 - ghc-tickets

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 30 May '18

30 May '18

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Phab:D4366 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1d1e2b77fdc2babdf4fff72b9120c6831e7b422f/ghc" 1d1e2b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d1e2b77fdc2babdf4fff72b9120c6831e7b422f" Implement "An API for deciding whether plugins should cause recompilation" This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *)
by GHC 30 May '18

30 May '18

#13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *) -------------------------------------+------------------------------------- Reporter: harry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My Compiler told me to report this so here you go: {{{ [1 of 1] Compiling Main ( ghc_bug.hs, interpreted ) ghc_bug.hs:3:1: warning: [-Wdeferred-type-errors] * Couldn't match expected type `IO t0' with actual type `() -> ()' * Probable cause: `main' is applied to too few arguments In the expression: main When checking the type of the IO action `main' ghc_bug.hs:3:8: warning: [-Wdeferred-type-errors] * Couldn't match expected type `() -> () -> ()' with actual type `()' * The function `()' is applied to one argument, but its type `()' has none In the expression: () () In an equation for `main': main = () () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): corePrepPgm [False] cobox_r1a0 = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:3:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs main :: () -> () main = () () }}} which that in "ghc_bug.hs" "ghc ghc_bug.hs -fdefer-type-errors -dcore-lint -v" gives me the following: {{{ Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/lib/ghc-8.0.1/package.conf.d/package.cache Using binary package database: /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d/package.cache loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *ghc_bug.hs !!! Chasing dependencies: finished in 0.42 milliseconds, allocated 0.211 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = ****-**-** **:**:**.********** *** ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file ghc_bug.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( ghc_bug.hs, ghc_bug.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.14 milliseconds, allocated 0.089 megabytes *** Renamer/typechecker [Main]: !!! Renamer/typechecker [Main]: finished in 28.70 milliseconds, allocated 14.769 megabytes *** Desugar [Main]: Result size of Desugar (after optimization) = {terms: 19, types: 52, coercions: 4} *** Core Linted result of Desugar (after optimization): *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: [RHS of cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *)] The type of this binder is primitive: cobox_aOD Binder's type: ((() -> ()) :: *) ~# (IO Any :: *) *** Offending Program *** main :: () -> () [LclIdX, Str=DmdType] main = case typeError @ 'VoidRep @ (() :: *) ~# ((() -> () -> ()) :: *) "ghc_bug.hs:2:8: error:\n\ \ * Couldn't match expected type `() -> () -> ()'\n\ \ with actual type `()'\n\ \ * The function `()' is applied to one argument,\n\ \ but its type `()' has none\n\ \ In the expression: () ()\n\ \ In an equation for `main': main = () ()\n\ \(deferred type error)"# of cobox_aOE { __DEFAULT -> (() `cast` (Sub cobox_aOE :: (() :: *) ~R# ((() -> () -> ()) :: *))) () } $trModule :: Module [LclIdX, Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *) [LclId[CoVarId], Str=DmdType] cobox_aOD = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:2:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# main :: IO Any [LclIdX, Str=DmdType] main = runMainIO @ Any (main `cast` (Sub cobox_aOD :: ((() -> ()) :: *) ~R# (IO Any :: *))) *** End of Offense *** <no location info>: error: Compilation had errors *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} and gcc version is: gcc version 7.1.1 20170516 (GCC) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14969: panic on incorrect syntax
by GHC 30 May '18

30 May '18

#14969: panic on incorrect syntax -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- With a fresh build of 8.5: {{{ GHCi, version 8.5.20180323: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/leo/.ghci Prelude> 3 _ 4 ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180323 for x86_64-apple-darwin): ASSERT failed! 2 1 t_a4j6[tau:1] Maybe a_a4j7[tau:2] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1157:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1213:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:720:54 in ghc:TcMType }}} I believe this fails in earlier versions as well, but I haven't tested it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies
by GHC 30 May '18

30 May '18

#15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The following compiles with both GHC 8.2.2 and 8.4.1: {{{#!hs newtype Drain = Drain { _drain :: Word8 } deriving stock (Eq, Ord, Show, Generic) deriving newtype (Storable) deriving anyclass (NFData) }}} However, adding `Prim` beside `Storable` in the `newtype` area yields the following with GHC 8.2.2: {{{ /home/colin/code/haskell/mapalgebra/lib/Geography/MapAlgebra.hs:1148:21-24: error: • Illegal unboxed tuple type as function argument: (# ghc-prim-0.5.1.1:GHC.Prim.State# s1, Word8 #) • In the expression: ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain) primitive-0.6.3.0:Data.Primitive.Types.readByteArray# In an equation for ‘primitive-0.6.3.0:Data.Primitive.Types.readByteArray#’: primitive-0.6.3.0:Data.Primitive.Types.readByteArray# = ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain) }}} and this with GHC 8.4.1: {{{ Illegal kind: ((:) (ghc-prim-0.5.2.0:GHC.Types.TupleRep ([] :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeR ep)) ((:) ghc-prim-0.5.2.0:GHC.Types.LiftedRep ([] :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc- prim-0.5.2.0:GHC.Types.RuntimeRep) Did you mean to enable TypeInType? | 1132 | deriving newtype (Storable, Prim) | }}} Turning on `TypeInType` as it suggests gives the same `Illegal unboxed tuple...` error. I've hand-written `Storable` instances before so I'm confident in its derivation, but I otherwise know nothing about `Prim`. Is there something magical about it that prevents it from being newtype derived in the same way? Thank you kindly, Colin -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15060: outofmem testcase sometimes crashes on i386
by GHC 30 May '18

30 May '18

#15060: outofmem testcase sometimes crashes on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Specifically in the `normal` way with, {{{ Actual stderr output differs from expected: --- ./rts/outofmem.run/outofmem.stderr-ws-32.normalised 2018-04-19 13:57:35.386373403 +0000 +++ ./rts/outofmem.run/outofmem.run.stderr.normalised 2018-04-19 13:57:35.386373403 +0000 @@ -1 +1,4 @@ -outofmem: out of memory (requested 1074790400 bytes) +outofmem: internal getMBlock: mmap: Invalid argument + (GHC version 8.5.20180419 for i386_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug +Aborted *** unexpected failure for outofmem(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets
by GHC 30 May '18

30 May '18

#15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets --------------------------------+--------------------------------- Reporter: ggardet | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- While trying to build GHC 8.4.2, we face the following error: {{{ [15143s] ghc-stage1: panic! (the 'impossible' happened) [15143s] (GHC version 8.4.2 for arm-unknown-linux): [15143s] Failed to lookup the datalayout for armv7l-unknown-linux- gnueabihf; available targets: ["i386-unknown-windows","i686-unknown- windows","x86_64-unknown-windows","arm-unknown-linux-gnueabihf","armv6 -unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","armv7a-unknown-linux- gnueabi","i386-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown- linux-gnu","x86_64-unknown-linux","armv7-unknown-linux- androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} So, we should add armv7l-unknown-linux-gnueabihf to ./utils/llvm-targets /gen-data-layout.sh and regenerate llvm-targets file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt
by GHC 30 May '18

30 May '18

#14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 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: -------------------------------------+------------------------------------- This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and- then-calculating-len-causes-ghc-to-consume-lots). With GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it: {{{ Prelude> l = length [1..10^8] Prelude> l 10000000 Prelude> }}} allocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends. In contrast, directly evaluating the expression or assigning it with a let-statement does **not** exhibit this behavior: {{{ Prelude> length [1..10^8] 10000000 Prelude> let l = length [1..10^8] Prelude> l 10000000 Prelude> }}} Also, loading the top-level declaration from a file and then evaluating it at the prompt does **not** exhibit the problem. I took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs. I verified that the bug still exists on the current "master" branch (though I didn't check the "ghc-8.4" branch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described
by GHC 30 May '18

30 May '18

#15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple ScopedTypeVariables | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider these dead-simple examples that use a signature with `tyvars` on a pattern {{{ -- no separate signature for bar, baz; tyvar aa not in scope from anywhere bar (x :: aa) = x :: aa baz (Just (x :: aa)) = x :: aa -- there could be signatures for bar, baz; they might use tyvar aa; but -- bar :: aa -> aa -- } no explicit forall -- baz :: Maybe aa -> aa -- } }}} Those equations with signatures on the patterns aren't valid Haskell 2010, so ghc rejects and suggests you need `ScopedTypeVariables`. Then they compile OK. Would I expect from [https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/glasgow_exts… #lexically-scoped-type-variables the User Guide documentation] those equations to be valid? I think not, and I see lots of questions on StackOverflow from people confused why they must use explicit `forall` -- and some equally confused answers failing to mention that no you don't necessarily. Arguably, all of the examples in the docos could be expressed equivalently (and less confusingly for beginners) using this style with pattern signatures rather than explicit `forall` bindings. (Misleading) snippets from the docos: [[BR]][[BR]] > 10.16 Enable lexical scoping of type variables explicitly introduced with `forall`. This comment is indented, so is really explaining that `ScopedTypeVariables` implies `ExplicitForall`. But it fails to explain that you're not forced to use explicit `forall`. [[BR]][[BR]] > 10.16 opening example[[BR]] > The type signature for `f` brings the type variable `a` into scope, because of the explicit `forall` ... Fails to mentin that you could achieve the same effect without explicit `forall`. [[BR]][[BR]] > 10.16.4 ... in all patterns ''other'' than pattern bindings, a pattern type signature may mention a type variable that is not in scope; in this case, ''the signature brings that type variable into scope''. This ''might'' be telling that the `bar, baz` above examples are valid, but there is not an example. Furthermore the comment following the `MkT` existential data constructor example undermines that interpretation: > ... in this situation (and only then), a pattern type signature can mention a type variable that is not already in scope ... If all this seems a little odd, ... What is "this situation"? What is "this" that seems odd? The pattern signature binding `(MkT [t :: a])` looks the same as `baz` above's `(Just (x :: aa))`; it's merely that `Just` is not existential. There might be a signature given for `baz`, and it might use `tyvar aa`. But it ''doesn't'' bring `aa` into scope for the equations **unless** that signature has explicit `forall`. That's not made clear. My first several readings of "situation (and only then) ... odd ..." were that this style of pattern signature to bind a `tyvar` applied only for existentials. [[BR]][[BR]][[BR]] BTW, some of the examples in the docos are not valid Haskell/give compilation errors because of lack of `( )` round the patterns with signatures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE
by GHC 30 May '18

30 May '18

#15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On powerpc64 validating HEAD I see the following failure: {{{ libraries/ghci/GHCi/InfoTable.hsc:323:20: error: [-Wunused-matches, -Werror=unused-matches] Defined but not used: ‘ex_ptr’ | 323 | pokeConItbl wr_ptr ex_ptr itbl = do | ^^^^^^ libraries/ghci/ghc.mk:4: recipe for target 'libraries/ghci/dist- install/build/GHCi/InfoTable.o' failed }}} Patch is coming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15190: disable haddock disables building of manuals
by GHC 29 May '18

29 May '18

#15190: disable haddock disables building of manuals -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As far as I can tell disabling haddock in ghc causes the manuals also not to get built. This is known/expected? I have not been able to track down why this seems to be the case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2