- ghc-tickets - Haskell.org

[GHC] #16047: Incorrect hscTarget in DynFlags when building hs-boot files
by GHC 18 Dec '18

18 Dec '18

#16047: Incorrect hscTarget in DynFlags when building hs-boot files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- We don't generate code for hs-boot files, but currently `hscTarget` field of `DynFlags` does not reflect that and we see `HscAsm` etc. when building boot files. I think we should see `HscNothing` instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15995: Make Control.Concurrent.QSem a newtype
by GHC 18 Dec '18

18 Dec '18

#15995: Make Control.Concurrent.QSem a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | 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: -------------------------------------+------------------------------------- {{{#!hs data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} I think this should be a newtype. The strictness annotations on the outter `MVar` could just be at each site where pattern matching on the `QSem`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found
by GHC 18 Dec '18

18 Dec '18

#15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Against expectations, the GHC bindist supposedly having DWARF support provided at https://downloads.haskell.org/~ghc/8.4.4/ghc-8.4.4-x86_64-deb9-linux- dwarf.tar.xz doesn't actually have DWARF support. According to bgamari, this is because `./configure --enable-dwarf-unwind` doesn't actually complain when the required dependency `libdw` isn't found; instead, it continues silently. Most programs I know will barf out when something isn't found but also *explicitly* requested via the command line; for the cases where this wasn't, the project maintainers did consider this a bug. GHC's `./configure` suite should fail hard when `--enable-dwarf-unwind` is given but `libdw` cannot be found. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16032: Compile speed regression
by GHC 17 Dec '18

17 Dec '18

#16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- GHC 8.6.3 seems to be about 10% slower than GHC 8.4.4 compiling a large input. The times goes from 22.25m to 24.5m. Unfortunately, I cannot include the modules to reproduce it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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