- ghc-tickets - Haskell.org

[GHC] #10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp Bool)
by GHC 12 May '15

12 May '15

#10405: Pattern synonym fails with (Exp Bool) but works with (t ~ Bool => Exp Bool) -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Compiler | Operating System: Linux (Type checker) | Type of failure: GHC rejects Keywords: | valid program Architecture: x86 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following compiles just fine: {{{#!hs data Exp a where B :: Bool -> Exp Bool pattern Tru = B True pr :: Exp a -> String pr Tru = "true" }}} but add a signature to `Tru`… {{{#!hs pattern Tru :: Exp Bool pattern Tru = B True }}} …and it fails to compile {{{#!hs % ghci -ignore-dot-ghci /tmp/Bug.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Bug.hs, interpreted ) /tmp/Bug.hs:11:4: Couldn't match type ‘a’ with ‘Bool’ ‘a’ is a rigid type variable bound by the type signature for pr :: Exp a -> String at /tmp/Bug.hs:10:7 Expected type: Exp a Actual type: Exp Bool Relevant bindings include pr :: Exp a -> String (bound at /tmp/Bug.hs:11:1) In the pattern: Tru In an equation for ‘pr’: pr Tru = "true" Failed, modules loaded: none. }}} Checking the inferred type of `pattern Tru = B True` I get {{{#!hs ghci> :i Tru pattern Tru :: t ~ Bool => Exp t }}} which works as expected {{{#!hs pattern Tru :: t ~ Bool => Exp t pattern Tru = B True pr :: Exp a -> String pr Tru = "true" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 12 May '15

12 May '15

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by ekmett): One reason for not following semver exactly is that the PVP doesn't line up exactly with semver. Both of our first two digits are "major", and we allow as many subsequent digits as we want. We also don't have an observable prerelease tag for better or worse. As for version tags being ignored by the `Eq` instance. That would have been a viable alternative, but it would have meant that `Version` still didn't line up with what we use it for in ghc, cabal, and elsewhere. IIRC the main use of the tags currently is to talk about a version "*" in some internals in places. A "structural" `Eq` has the benefit that `x == y` implies `f x == f y`, and doesn't require the user to track the exception to the semantics they expect for equality, whereas under your suggestion we'd lose that. It'd just be 'some place to shove extra stuff' bolted onto a data type that could be fundamentally simpler. Then if users want to work with a tagged version they can build it by one of several means, for whatever notions of tags they want to allow, using the existing `Version` type as a primitive component in their own tagged version type with tags being relevant or not for equality as they choose. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10384: "Can't splice the polymorphic local variable" check looks dead
by GHC 12 May '15

12 May '15

#10384: "Can't splice the polymorphic local variable" check looks dead -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template | Version: 7.11 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While I was looking for TH checks which might want to be checked when `Quotes` are enabled ala #10382, I found the "Can't splice the polymorphic local variable" check in `checkCrossStageLifting` in `TcExpr`. I thought this was a bit odd, because there is another implementation of this very function in `RnSplice`. So I went ahead and removed this check from the compiler, and it validated fine. I then went and tried to see if I could tickle the problem. An old mailing list suggested the following test program to induce the error: {{{ module TH_polymorphic where import Language.Haskell.TH import Language.Haskell.TH.Syntax -- See https://mail.haskell.org/pipermail/template- haskell/2006-April/000552.html test2 () = runQ [| foldr f z xs |] where (f,z,xs) = undefined }}} but I get this error: {{{ TH_polymorphic.hs:8:17: error: Could not deduce (Lift t0) arising from a use of ‘lift’ from the context: Quasi m bound by the inferred type of test2 :: Quasi m => () -> m Exp at TH_polymorphic.hs:(8,1)-(9,30) The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance (Lift a, Lift b) => Lift (Either a b) -- Defined in ‘Language.Haskell.TH.Syntax’ instance Lift a => Lift (Maybe a) -- Defined in ‘Language.Haskell.TH.Syntax’ instance Lift Int16 -- Defined in ‘Language.Haskell.TH.Syntax’ ...plus 24 others In the expression: lift xs In the first argument of ‘runQ’, namely ‘[| foldr f z xs |] pending(rn) [<xs, lift xs>, <z, lift z>, <f, lift f>]’ In the expression: runQ [| foldr f z xs |] pending(rn) [<xs, lift xs>, <z, lift z>, <f, lift f>] }}} which seems to be induced the check in `RnSplice`. So is it dead? If so, let's remove it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The return/pure thing presumably arises because we have `return = pure`, or vice versa, and one is "shorted out" in favour of the other. See `SimplCore.shortOutIndirections`. Would someone like to see if this is true? If someone cares to confirm this, then perhaps `shortOutIndirections` could choose whether to elminate `return` or eliminate `pure` based on a lexicographic comparison of their names? Would someone like to see if this would work? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:81> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 11 May '15

11 May '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: #8977 => #8977, #10298 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 11 May '15

11 May '15

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by rodlogic): Replying to [comment:19 zilinc]: > I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the `VersionTags` field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in `Setup.hs`. So that the `showVersion` function can print something like `MySoftware 2.3.0.0-ce78942aed`, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in `PackageDescription` to keep extra notes? I also share the same feeling and sorry for being late to comment here. This is quite a common pattern out there. Removing versionTags to avoid the Eq/Ord inconsistency seems like the easiest approach but not the best one, imho. Why not stick to semver.org: MAJOR.MINOR.PATCH(-PRERELEASE)?(+tag)*, where: * "Pre-release versions have a lower precedence than the associated normal version" * "Build metadata SHOULD be ignored when determining version precedence" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries"
by GHC 11 May '15

11 May '15

#10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This was originally spotted and [https://mail.haskell.org/pipermail/ghc- devs/2015-February/008407.html posted to the ghc-devs mailing list] by Joachmin Breitner, but apparently since nobody has submitted a ticket for this relatively serious issue, here it is. I am quoting Joachim: {{{ while the index at http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/index.… exists, navigating to http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/Data- Char.html yields a 404 error. Same for http://haskell.inf.elte.hu/docs/latest/html/libraries/Data-Char.html }}} And [https://mail.haskell.org/pipermail/ghc-devs/2015-February/008408.html I have replied] the following to his initial email (I am involved in this because I am doing daily snapshots of the documentation through my FreeBSD GHC builders): {{{ Yes, I can confirm this bug. For what it is worth, the files are all there, the link appears to be broken: it is missing the subdirectory with the name of the package. That is, the proper link should be something like that: http://haskell.inf.elte.hu/docs/7.9.20141222.noWin32/html/libraries/base-4.… /Data-Char.html (Note the missing "base-4.8.0.0".) I have checked this with GHC 7.8.3, and everything is right there, while this problem seems to appear with GHC 7.10 RC2 and GHC-HEAD (starting from somewhere between mid-September and November -- that is what a quick bisecting tells me). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10302: 7.10.1 documenation is incorrect wrt llvm
by GHC 11 May '15

11 May '15

#10302: 7.10.1 documenation is incorrect wrt llvm -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: llvm | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As documented in [#9929] ghc 7.10.1 only supports llvm 3.5. This should be documented in the release notes section of the GHC Users's Guide, Version 7.10.1. In addition, the following in the Known bugs section needs to be changed to mention this also: GHC’s LLVM backend is currently incompatible with LLVM 3.4 (issue #9929). The following in section 4.11.2 should also be changed from: Currently LLVM 2.8 and later are supported. to Only LLVM 3.5 is supported. from Secondly, if you are running Mac OS X with LLVM 3.0 or greater to Secondly, if you are running Mac OS X with LLVM 3.5 from In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X. to In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X and then install LLVM 3.5 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > There are some issues with non-determinism in the output of GHC, which > means that compilations are not repeatable. This affects some users > (e.g. Debian packagers) who need to be able to get repeatable hashes for > the packages of a GHC build. > > The cases we know about that lead to non-deterministic results are: > > * The `spec_ids` (specialised Ids) attached to an Id have a non- > deterministic ordering > * CSE can give different results depending on the order in which the > bindings are considered, and since the ordering is non-deterministic, the > result of CSE is also non-deterministic. e.g. in `x = z; y = z; z = 3`, > where `y` and `x` are exported, we can end up with either `x = y; y = 3` > or `y = x; x = 3`. > * There seems to be something unpredictable about the order of arguments > to SpecConstr-generated specialisations, see > [http://www.haskell.org/pipermail/glasgow-haskell- > users/2011-April/020287.html] > * The wrappers generated by the `CApiFFI` extension have non- > deterministic names. (see comment:15 below). > > '''Old ticket description follows''' > > Short story: if you use ghc-6.12.1.20100318 (or similar, probably > ghc-6.12.1 release will produce the same results) to bootstrap > ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12, > those two instances of ghc-6.12 will have different ABI hashes and > interfaces in the ghc package. If you use ghc-6.10 for the > bootstrapping, you'll even get differences in the ghc, base and > Cabal packages. > > Long story: see logfiles and descriptions at http://darcs.volkswurst.de > /boot-tests/ (note that the logfiles are quite large, I really don't want > to attach 150 MB of logs to this ticket). New description: There are some issues with non-determinism in the output of GHC, which means that compilations are not repeatable. This affects some users (e.g. Debian packagers) who need to be able to get repeatable hashes for the packages of a GHC build. The cases we know about that lead to non-deterministic results are: * The `spec_ids` (specialised Ids) attached to an Id have a non- deterministic ordering * CSE can give different results depending on the order in which the bindings are considered, and since the ordering is non-deterministic, the result of CSE is also non-deterministic. e.g. in `x = z; y = z; z = 3`, where `y` and `x` are exported, we can end up with either `x = y; y = 3` or `y = x; x = 3`. * There seems to be something unpredictable about the order of arguments to SpecConstr-generated specialisations, see [http://www.haskell.org/pipermail/glasgow-haskell- users/2011-April/020287.html] * The wrappers generated by the `CApiFFI` extension have non- deterministic names. (see comment:15 below). * See comment:76 for another, different, example '''Old ticket description follows''' Short story: if you use ghc-6.12.1.20100318 (or similar, probably ghc-6.12.1 release will produce the same results) to bootstrap ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12, those two instances of ghc-6.12 will have different ABI hashes and interfaces in the ghc package. If you use ghc-6.10 for the bootstrapping, you'll even get differences in the ghc, base and Cabal packages. Long story: see logfiles and descriptions at http://darcs.volkswurst.de /boot-tests/ (note that the logfiles are quite large, I really don't want to attach 150 MB of logs to this ticket). -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:80> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for bringing this up Mateusz. The ticket description lists four sources of non-deterministic outputs. I think you are saying that 7.10.1 has a fifth (as yet uncharacterised) source, which somehow bites more often than the preceding four. Is that right? Is comment:76 the single exemplar of the difficulty, or are there others? Mateusz says that we should not release 7.10 until comment:76 is fixed. Do others agree? Does anyone feel able to characterise what is going on with comment:76? Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:79> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0