September 2017 - ghc-tickets

[GHC] #9642: LANGUAGE pragma synonyms
by GHC 11 Nov '17

11 Nov '17

#9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here are the first 20 lines of a typical Haskell file of mine: {{{ {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE LiberalTypeSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ConstraintKinds #-} }}} Over a couple of modules in a small package, I find myself copy-pasting these 20 lines, as either I will use these extensions, or they won't really cause any harm to the code I'm writing. As a way to simplify this, and reduce code duplication, I propose introducing LANGUAGE pragma synonyms: {{{ {-# LANGUAGE PedrosHaskell = EmptyDataDecls, FlexibleContexts, FlexibleInstances , LiberalTypeSynonyms, ScopedTypeVariables , RankNTypes, StandaloneDeriving, AutoDeriveTypeable , DeriveDataTypeable, DeriveGeneric, DefaultSignatures , OverlappingInstances, UndecidableInstances , MultiParamTypeClasses, TypeOperators, TypeFamilies , GADTs, DataKinds, PolyKinds, ConstraintKinds #-} }}} After writing this, in that same module or any module that imports it, I could just write: {{{ {-# LANGUAGE PedrosHaskell #-} }}} And all the pragmas above would be enabled. Besides making my life easier, I suspect this will also help increase modularity of certain packages. For example, packages could define a package-specific language pragma that should be enabled in order to use that package. Then, if the package maintainer upgrades one datatype to become a GADT, the pragma would be updated to include `GADTs`, and user code (that could now be requiring that pragma) would automatically enable `GADTs` too. Furthermore, it can also make the language standardisation process simpler. After all, {{{ {-# LANGUAGE Haskell2010 = PatternGuards, NoNPlusKPatterns, RelaxedPolyRec , EmptyDataDecls, ForeignFunctionInterface #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12623: Make Harbormaster less terrible in the face of submodule updates
by GHC 11 Nov '17

11 Nov '17

#12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamarii Type: task | Status: new Priority: highest | 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: -------------------------------------+------------------------------------- Currently submodule updates appear to break Harbormaster builds. This is bad. Fix it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13122: Investigate reporting build errors with harbormaster.sendmessage
by GHC 11 Nov '17

11 Nov '17

#13122: Investigate reporting build errors with harbormaster.sendmessage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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 phabricator API provides a method `harbormaster.sendmessage` which allows builds to report information back so that it is displayed on the interface. The goal is to avoid having to delve into the build logs in order to investigate failures. Information about the API method can be found in [https://phabricator.haskell.org/conduit/method/harbormaster.sendmessage/ conduit]. The API provides a rich set of options to report different information about a build. Some ideas: * Reporting the precise location of all terminal build errors * Reporting the outcome of all tests (this might be quite noisy but the only way to see is to try!) I don't know whether this is a good idea or how it works precisely but integrating harbourmaster with differential would be an efficiency gain. This is potentially related to #8809. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

11 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 11 Nov '17

11 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] #13795: :kind! is not expanding type synonyms anymore
by GHC 08 Nov '17

08 Nov '17

#13795: :kind! is not expanding type synonyms anymore --------------------------------------+--------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Given {{{#!hs type A = () :kind! A }}} Expected result: {{{#!hs A :: * = () }}} Actual result: {{{#!hs A :: * = A }}} ---- Some IRC conversation on the topic (on #ghc): {{{ 23:37 < hjulle> :kind! does not seem to expand type synonyms for me (in GHC 8.0.2), it just prints them verbatim. Does anyone else have this problem? Example: "type A = ()" ":kind! A" will print out "A :: * = A" (which is not very helpful). 23:40 < hjulle> Is this a bug? The documentation (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #ghci-cmd-:kind) explicitly states that :kind! should expand type synonyms, so I think yes? 23:57 < RyanGlScott> hjulle: That's absolute a bug. File a ticket! 23:57 < RyanGlScott> *absolutely 23:58 < RyanGlScott> Moreover, I know why that's happening 23:59 < RyanGlScott> Internally, :kind! uses the normalise_type function to reduce type families: http://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab21… 23:59 < RyanGlScott> But see the comment there Day changed to 07 jun 2017 00:00 < RyanGlScott> -- Try to not to disturb type synonyms if possible 00:01 < RyanGlScott> So fixing this would just be a matter of calling coreView afterwards (which expands type synonyms) 00:02 < RyanGlScott> er, actually, expandTypeSynonyms is even better: http://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab21… }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[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