December 2018 - ghc-tickets

[GHC] #15923: Skip performance tests if not in a git repo
by GHC 17 Dec '18

17 Dec '18

#15923: Skip performance tests if not in a git repo -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12758 Differential Rev(s): | Wiki Page: | Performance/Tests -------------------------------------+------------------------------------- As of #12758 performance tests now compare to the results of the previous commit. Results are stored in git notes. If for some reason the rood directory is not a git repo, we have no results to compare to, nor can we save the new results to git notes. Hence we should skip all performance tests. Such a use case was encountered in simonpj's workflow where he copies/syslinks the work tree without the .git directory before validating. An open question is can we allow performance testing while not in a git repo or by adjusting the workflow? Tasks: * When the ghc root directory is not a git repository, skip all performance tests. * Update the [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests wiki page]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16019: Harbormaster: OS X build fails
by GHC 17 Dec '18

17 Dec '18

#16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime | Version: 8.7 System | Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Build 64479 https://phabricator.haskell.org/harbormaster/build/64479/ {{{ rts/sm/CNF.c:1002:13: error: 486 error: declaration does not declare anything [-Werror ,-Wmissing-declarations] 487 FALLTHROUGH; 488 ^ 489 | 490 1002 | FALLTHROUGH; 491 | ^ 492 493 includes/Stg.h:201:21: error: 494 note: expanded from macro 'FALLTHROUGH' 495 | 496 201 | #define FALLTHROUGH GNU_ATTRIBUTE(fallthrough) 497 | ^ 498 #define FALLTHROUGH GNU_ATTRIBUTE(fallthrough) 499 ^ 500 501 includes/Stg.h:188:27: error: 502 note: expanded from macro 'GNU_ATTRIBUTE' 503 | 504 188 | #define GNU_ATTRIBUTE(at) __attribute__((at)) 505 | ^ 506 #define GNU_ATTRIBUTE(at) __attribute__((at)) 507 ^ }}} Marking this as highest priority because it is a regression and it breaks CI. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15950: Hadrian build fails on Windows
by GHC 17 Dec '18

17 Dec '18

#15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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: -------------------------------------+------------------------------------- As of {{{ $ hadrian/build.cabal.sh -j5 --flavour=Quick ... $ hadrian/build.cabal.sh -j5 --flavour=Quick | ContextData oracle: resolving data for 'iserv' (Stage1, v)... | Configure package 'iserv' Configuring iserv-8.7.1... creating C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--numeric-version" ]0;1s (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "--version" C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--supported-languages" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- info" Reading installed packages... "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "dump" "--global" "-v0" "--global-package- db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--print-libdir" "-ghcversion- file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" CallStack (from HasCallStack): die', called at .\Distribution\Simple\Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configureFinalizedPackage, called at .\Distribution\Simple\Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configure, called at .\Distribution\Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks configureAction, called at .\Distribution\Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainWithHooksNoReadArgs, called at src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse hadrian.exe: Encountered missing dependencies: libiserv ==8.7.* }}} (Ignore garbage characters due to Window's broken ANSI console support) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15950> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16044: Transition to C11 memory model
by GHC 17 Dec '18

17 Dec '18

#16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 System | 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: -------------------------------------+------------------------------------- Following offline discussion with Ben Gamari and [https://mail.haskell.org/pipermail/ghc-devs/2018-November/016581.html Cmm Memory Model thread on ghc-devs@], I would like to propose to gradually transition RTS and Cmm to C11 memory model. There are multiple benefits: 1) Correctness: C11 atomics are properly specified and are easier to reason about than the existing SMP.h barriers. 2) Performance: compilers can optimize and generate better code for C11 atomics. For example, on ARMv8 acquire/release operations use specialized LDA/STL instructions. 3) Tooling support: once all code transitions to C11 atomics, tools like ThreadSanitizer can be used to find subtle data races. To make sure that code continues to compile with old compilers (pre C11), I plan to introduce wrapper functions (acquire_load, release_store, etc.) that are implemented either using C11 atomics or SMP.h barriers depending on the STDC_VERSION. Here is a [https://github.com/ulan/ghc/commit/0e8822a8038c3d0c770f4582c8f65b20d7823769 prototype implementation]. The idea is that newly written code should use the wrappers and we can gradually update the existing code. I think updating C code in RTS would work with this approach, but I am not sure about Cmm. Please let me know if you see potential issues, a better way to implement it, or oppose moving to C11 memory model. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14146: Can GHC propose kind restrictions?
by GHC 17 Dec '18

17 Dec '18

#14146: Can GHC propose kind restrictions? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This is UX. As my code gets more polykinded I find myself in situations such as these all the more often {{{#!hs instance (Comonad f, Representable f, Comonad g, Representable g) => Comonad (Compose f g) where extract = undefined duplicate = undefined instance ComonadApply (Compose f g) where (<@>) = undefined }}} {{{ /tmp/a.hs:20:10-35: error: • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration • In the instance declaration for ‘ComonadApply (Compose f g)’ | 20 | instance ComonadApply (Compose f g) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. }}} It would help me if GHC looked up a `Comonad (Compose _ _)` instance, compared the kinds {{{#!hs Comonad (Compose (f :: Type -> Type) (g :: Type -> Type) :: Type -> Type) ComonadApply (Compose (f :: k -> Type) (g :: Type -> k) :: Type -> Type) }}} a simple suggestion like this would be helpful {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a kind signature (ComonadApply (Compose (f :: Type -> Type) g)). }}} Even more amazing would be {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a context (Comonad f, Representable f, Comonad g, Representable g) => ComonadApply (Compose f g) }}} Which the compiler could in theory guess, since following GHC's suggestion iteratively you end up with {{{#!hs ComonadApply (Compose (f :: Type -> Type) g) -- ==> add (Comonad f) to the context of the instance declaration Comonad f => ComonadApply (Compose f g) -- ==> add (Comonad g) to the context of the instance declaration (Comonad f, Comonad g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g, Representable f) => ComonadApply (Compose f g) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13992: Error message, room for improvement (polykinds)
by GHC 17 Dec '18

17 Dec '18

#13992: Error message, room for improvement (polykinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something like {{{#!hs -- • No instance for (Show (Compose Proxy Proxy a)) -- arising from the 'deriving' clause of a data type declaration -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Show (FlipProxy a)) {-# Language DerivingStrategies, GeneralizedNewtypeDeriving, PolyKinds, KindSignatures #-} import Data.Functor.Compose import Data.Proxy import Data.Kind newtype FlipProxy a = FlipProxy_ (Compose Proxy Proxy a) deriving newtype Show }}} where the solution is to constraint the kind of `a :: Type`, it would be nice if GHC could reference kind variables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16061: Missing FreeBSD build for 8.6.2
by GHC 17 Dec '18

17 Dec '18

#16061: Missing FreeBSD build for 8.6.2 -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.2 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Documentation (amd64) | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://www.haskell.org/ghc/download_ghc_8_6_2.html#freebsd11_x86_64 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16061> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16060: Missing AArch64 builds for latest GHC 8.6.3
by GHC 17 Dec '18

17 Dec '18

#16060: Missing AArch64 builds for latest GHC 8.6.3 -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Documentation | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here there is a link to AArch64, but there is no such a section: https://www.haskell.org/ghc/download_ghc_8_6_3.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself
by GHC 17 Dec '18

17 Dec '18

#15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- And more generally, is there any chance that we could make something like our builder `Args`/predicate logic work for specifying arguments to hadrian itself? Regardless of the answer to that last question, it seems only natural to have a simple/trivial solution for the case where we are always passing the same options to hadrian, over and over again, while working on GHC. "Yes, hadrian, I still want to build with the `perf` flavour, still with `integer-simple`, and you should still put all the build artifacts under `./ghc-prof-build/` while using all of my 4 cores", is something that I often told hadrian myself, while investigating a particular problem a few weeks ago, for example. Ryan in particular has expressed interested in having a slightly cleaner solution than writing a tiny wrapper script that just does `hadrian/build.sh --flavour=perf -oghc-prof-build $@` or something along those lines. Especially given that our `Args` infrastructure seems perfect to specify that kind of thing. It does seem a little bit circular though, of course. An alternative would be look at a build.mk-ish file, without support for any Make construct, just the good old key=value syntax + comments, and reconstruct a `Flavour` and everything else out of it. This way, instead of "implicitly" passing the same arguments on the CLI, we would "implicitly" look them up from some file, without having to create a wrapper script. (This build.mk-ish file is something I discussed with hvr some time ago, which he would like so as to programmatically specify how he wants his GHCs. He can't reasonably programmatically edit the settings file.) Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #16055: libffi build logic is quite spread out
by GHC 16 Dec '18

16 Dec '18

#16055: libffi build logic is quite spread out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 rules for building libffi are in `Rules.Libffi` and at a first glance they just use the normal `Make` builder in order to build the project. However, if one looks carefully, you actually need to run `make install` so the normal `Make` builder has an argument appended in `Settings.Builders.Make`. The problem here is that the two modules are completely unrelated to each other. In order to discover this I had to wonder why the build was failing to copy a file and then by chance guess that it wasn't running `make install`. I think grepped for `"install"` and managed to find this additional rule. Is there a way to move this logic into one place? I considered two possibilities but it didn't seem to be "how things are done". 1. Modify the `Make` builder to take an additional argument which indicates whether to add the `install` flag. 2. Move the override of `Make` for libffi into `Rules.Libffi` and then import it into `Settings.Builders.Make`. This seems better but you still not entirely obvious what is going on. Do the hadrian experts have any opinion on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16055> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2