May 2017 - ghc-tickets

[GHC] #13121: Investigate whether uploading build artifacts from harbormaster would be usful
by GHC 10 Nov '17

10 Nov '17

#13121: Investigate whether uploading build artifacts from harbormaster would be usful -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In harbormaster it is possible to upload build artifacts and associate them with each build, for example we could upload the user manual for each build or even binaries. I am not sure what would be useful. One use case might be checking the rendering of the user guide when it is modified. The idea is to write a small utility program which uploads suitable artifacts and then add an extra build step to the relevant build plans which calls this program. The utility doesn't have to be in-tree as it can be installed in the environment. Some more information: * There are some bindings to the phabricator API in [https://github.com /haskell-infra/arc-lite arc-lite] * The relevant API methods are `file.allocate`, `file.upload` and `harbormaster.createartifact` * `file.allocate` allows you to specify a time to delete a file, this would be good to avoid consuming lots of storage for builds. * Artifacts appear in the "artifacts" tab [https://phabricator.haskell.org/harbormaster/build/18367/ here] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13716: Move CI to Jenkins
by GHC 10 Nov '17

10 Nov '17

#13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | 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: -------------------------------------+------------------------------------- Currently we use Harbormaster to build Differentials and commits. While this works, it leaves much to be desired, * job scheduling is (literally) random: this means that some patch authors end up waiting literally ways for their patches to be built * there is little support for automatic provisioning of builders: this means we can't scale to meet demand and make poor use of our computational resources * periodic builds (e.g. nightlies) are not supported. Ideally we would not only provide * it doesn't have a sensible interface for integration with external tools: this means that efforts like CI-before-merge have been pushed off * status reporting is poor: even answering the question of what a given builder is currently working on is surprisingly difficult * maintenance is a byzantine: Adding a new builder requires adding at least six different objects (a Harbormaster Build Plan, a Drydock Working Copy, a Drydock Blueprint, an Almanac Service, an Almanac Device, and an Almanac Binding) in various Phabricator applications. None of this configuration can be tracked under version control nor can most of it be cloned from an existing builder's configuration. * Design assumptions don't match GHC's constraints: Harbormaster was designed under the assumption that builds are cheap and computation plentiful. The maintainers have stated that they have little interest in supporting environments where this doesn't hold. Jenkins, while far from perfect, seems a bit better suited to our needs, more mature, and far more flexible. This ticket will serve as the checklist for our move to Jenkins. In the end we want, * Builders (static or dynamically-provisioned, as appropriate) for * x86-64, i386 Linux * x86-64, i386 Windows * x86-64 Darwin * x86-64 OpenBSD * Cross compile from x86-64 to ARM * Native ARM * Differential builds with sensible scheduling (e.g. first build on 64-bit Linux where machines are cheap, then build on the others) * Per-commit builds on all * Nightly builds on all, including * Collection of binary distribution for user download * Update of `master` documentation mirror on downloads.haskell.org * Slow validation (including tests requiring Hackage packages) * nofib run on some platforms? * Test-before-merge-to-master -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12363: Type application for infix
by GHC 10 Nov '17

10 Nov '17

#12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `1 + @Int 10` is a parse error, I would like it to mean the same as {{{#!hs (+) @Int 1 10 }}} Thoughts? ---- Also {{{#!hs >>> pure `foldMap` @Maybe @[_] Just 'a' "a" >>> foldMap @Maybe @[_] pure (Just 'a') "a" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #8238: Implement unloading of shared libraries
by GHC 10 Nov '17

10 Nov '17

#8238: Implement unloading of shared libraries ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8039 | ------------------------------------+------------------------------------- In #8039 we added support for unloading static objects from the runtime linker, with the GC detecting when there are no references left. We could add this functionality for shared libraries too, using `dl_iterate_phdr`. @heisenbug's comment from #8039 with the relevant pointers: [http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared- libraries Eli Bendersky's article] suggests to use the [http://linux.die.net/man/3/dl_iterate_phdr dl_iterate_phdr] function for finding information about loaded libraries. Seems to be linux only. There is a [http://stackoverflow.com/questions/10009043/dl-iterate-phdr- equivalent-on-mac workaround on OSX], though, on !StackOverflow. And here is how Böhm-Demers-Weiser's GC implement a [https://github.com/ivmai/bdwgc/blob/master/dyn_load.c#L451 callback function for dl_iterate_phdr]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10514: Generic for existential types
by GHC 09 Nov '17

09 Nov '17

#10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: | Owner: ekmett andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: Core | Type of failure: None/Unknown Libraries | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have some use for Generic for an existential type which is constraint to be Generic. {{{!#hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE StandaloneDeriving #-} import GHC.Generics data U = forall a. (Generic a) => U a -- deriving (Generic) -- Can't make a derived instance of ‘Generic U’: -- Constructor ‘U’ has existentials or constraints in its type -- Possible fix: use a standalone deriving declaration instead -- deriving instance Generic U -- Can't make a derived instance of ‘Generic U’: -- U must be a vanilla data constructor -- In the stand-alone deriving instance for ‘Generic U’ data D1Ser data C1_0Ser instance Generic U where type Rep U = D D1Ser (C1 C1_0Ser (S1 NoSelector (Rep a))) -- Not in scope: type variable ‘a’ -- How to bring the existential type `a' into scope? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12791: Superclass methods could be more aggressively specialised.
by GHC 08 Nov '17

08 Nov '17

#12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: -------------------------------------+------------------------------------- Say `R` is a superclass of `MR` but only uses one of the type variables. If this type variable is fixed then we know that we are going to use the specific dictionary. Thus, the optimiser *could* specialise all methods from the superclass at this point leading to better code. {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts #-} module Foo where class R t => MR t m where push :: t -> m -> Int class R t where pull :: t -> Int --type MR2 t m = (R t, MR t m) instance MR Int Int where push = max instance R Int where pull = negate myf :: (MR Int a) => a -> Int -> Int myf _ = pull }}} To give a concrete example, `R` is a super class of `MR` but only mentions the first type variable. Thus when we fix it in `myf`, we could optimise the definition to `myf _ = negate` by inlining the class method. Reid points out that if you have a definition like {{{ data X = X f :: R X => Int -> Int f = pull }}} then the instance for `R X` could be provided by another module. However it is common to structure large applications with super class constraints so it would be desirable to do better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command
by GHC 04 Nov '17

04 Nov '17

#11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was playing around with GHCi's `:kind` command and noticed that trying to ascribe a type with a kind doesn't parse: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151219: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeInType λ> :kind 'True :: Bool <interactive>:1:7: error: parse error on input ‘::’ }}} This seems like something that should be able to parse, given that `:type True :: Bool` parses just fine. Is there a reason it couldn't? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12199: GHC is oblivious to injectivity when a type family is used in a GADT type
by GHC 04 Nov '17

04 Nov '17

#12199: GHC is oblivious to injectivity when a type family is used in a GADT type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://www.reddit.com/r/haskell/comments/4oeidw/type_family_dependencies_a… A reddit post] points out a limitation of injective type families: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilyDependencies #-} type family Foo a = b | b -> a where Foo Int = Bool data Bar :: * -> * where Bar :: a -> Bar (Foo a) oink :: Bar Bool -> Int oink (Bar x) = x -- type error }}} Compiling this fails with: {{{ Could not deduce: a ~ Int from the context: Bool ~ Foo a }}} Which seems odd, given that `Bool ~ Foo a` should imply `a ~ Int` by injectivity. Even if you change the type signature of `oink` to `Bar (Foo Int) -> Int`, it fails with: {{{ Could not deduce: a ~ Int from the context: Foo Int ~ Foo a }}} which makes it even more apparent that it isn't aware of the fact that `Foo` is injective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10577: Use empty cases where appropriate when deriving instances for empty types
by GHC 02 Nov '17

02 Nov '17

#10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In some sense the correct instance for {{{ data X deriving instance Eq X }}} is not (what GHC currently produces) {{{ instance Eq X where (==) = error "Void ==" }}} but rather {{{ instance Eq X where a == b = case a of {} -- using the EmptyCase extension }}} See comments starting at ticket:7401#comment:28 for justification. The list of classes that GHC can currently derive is * Eq, Ord, Enum, Bounded, Show, Read (Haskell 2010 Report) * Functor, Foldable, Traversable, Typeable, Generic, Data, "any class" (`-XDerive*`) Deriving Enum and Bounded is not currently allowed for empty data types. The `showList` method of Show and the whole Read instance are easy and already implemented correctly. All the remaining methods of Haskell 2010 derivable type classes take at least one argument of the instance head type `a`. I propose that all these methods be defined as an empty case on the first such argument. Similarly in Functor, Foldable and Traversable, each method has a single argument of the form `t _` where `t :: * -> *` is the instance head type, and the method should be defined as an empty case on that argument. In all these cases so far, the derived methods for a non-empty type would, at the outermost level, be a (non-empty) case on that first argument, or the equivalent (series of pattern matches, one for each constructor), so the use of an empty case is justified for an empty type. Typeable does not care about the values or even the kind of the type at all, so it's not relevant here. Generic and especially Data are above my pay grade, but generally I expect that methods which are normally defined by case analysis on an argument of the instance head type should be defined by an empty case, and methods that (sometimes) produce a value of the instance head type should do whatever they normally do when unable to produce such a value (like `readsPrec` returning an empty list, or `read` calling `error` (if `read` were actually a method of `Read`)). `DeriveAnyClass` doesn't generate any new code, so like Typeable it's not relevant. None of this behavior is specified by the Haskell 2010 Report, which disallows deriving any class for a type with no constructors; but see #7401. So, we are entitled to do what we think is best here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10871: Implement "buildable" interface files which can be directly compiled without source
by GHC 02 Nov '17

02 Nov '17

#10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. And maybe more we haven't thought of yet. The primary function you need to implement is a function from `ModIface`/`ModDetails` to `TcGblEnv`, which can then be fed to the desugarer. I'm looking at what things we need to add to `ModIface` to support this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28