- ghc-tickets - Haskell.org

[GHC] #15391: Maybe ghc-pkg register should unregister packages with "incompatible" signatures
by GHC 16 Jul '18

16 Jul '18

#15391: Maybe ghc-pkg register should unregister packages with "incompatible" signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.4.3 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following situation: 1. I register package 'p-0.1-inplace' instantiated with 'P = base:Data.Map' 2. I register package 'p-0.1-inplace' instantiated with 'P = base:Control.Monad' Even though the IPID of these two packages is the same, we clearly want to keep both of them in the database. This thus motivates the following lines in ghc-pkg {{{ removes = [ RemovePackage p | not multi_instance, p <- packages db_to_operate_on, mungedId p == mungedId pkg, -- Only remove things that were instantiated the same way! instantiatedWith p == instantiatedWith pkg ] }}} OK... now consider the following situation 1. I register package 'p-0.1-inplace' instantiated with 'P = base:Data.Map' 2. I register package 'p-0.1-inplace', instantiated with nothing (I have edited 'p' such that it has no more signatures) So... ghc-pkg is going to keep both of these packages (per the logic above). But is that really what we want? Now the package database is in a half-consistent state, where the instances of 'p-0.1-inplace' are not consistent with the number of holes they are supposed to have. So let us suggest an invariant: INVARIANT: All packages which have the same IPID in a package database are self-consistent with each other. OK, so given this invariant, what do we have to do in step 2? It would seem that when we get a prospective package to register, we must *find all packages which are incompatible with it*, and remove them from the package database. So, given a package with a set of holes H, we must remove all packages with holes H' such that H = H' I'm not completely convinced this is a good idea. Usually ghc-pkg only removes a single package in response to a new registration, and this behavior could result in lots of packages getting unregistered, more than you might expect. On the other hand, if you think of the package database in a more hierarchical manner, it makes sense that changing the root registration would invalidate all the children. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13812: deriveConstants: no objdump program given (OpenBSD)
by GHC 15 Jul '18

15 Jul '18

#13812: deriveConstants: no objdump program given (OpenBSD) -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: OpenBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: #9549 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building HEAD on OpenBSD 6.1 fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "gcc" --gcc-flag -W all --gcc-flag -std=gnu99 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist- derivedconstants/header --gcc-flag -Iincludes/di st-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "nm" --target-os "openbsd" deriveConstants: no objdump program given }}} This can be fixed in configure.ac (see attached patch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15374: Testsuite: compile_timeout_multiplier is fragile
by GHC 15 Jul '18

15 Jul '18

#15374: Testsuite: compile_timeout_multiplier is fragile -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I'm taking a sweep through the testsuite, trying to eliminate failures in a `DEBUG` compiler. But two tests are stymieing me: `pmcheck/should_compile/T11{276,374}`. Both of these use the `compile_timout_multiplier` option in their `all.T` entries. This option means that, instead of the normal 300s allotted to the test, these tests get only 3s. In my setup, with a `DEBUG` (read: unoptimized) stage2 compiler, these tests fail when I'm running the testsuite in parallel. Then, when I run the tests individually, they succeed. This poses two problems: 1. I can only see the failure when my machine is stressed, and it's disconcerting to have a failure appear and disappear depending on how I look. 2. There is (sometimes) a failure in `DEBUG` mode. What is the goal of `compile_timeout_multiplier`? If we're really testing performance (which #11276 and #11374 indicate), then these tests should be in `perf/compiler` and be "stat" tests, where some wibbling in the numbers is expected (and where `DEBUG` compilers are exempted). I would imagine that `compile_timeout_multiplier` should only ever get values greater than 1, when a non-performance test is so expensive to run that it takes more than 300s. As a local solution here, I think these two tests should move to `perf/compiler`. Other pattern-match tests also have `compile_timeout_multiplier`, too, and I can move these as well. Any objections? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14525: Backpack doesn't work with CPP
by GHC 14 Jul '18

14 Jul '18

#14525: Backpack doesn't work with CPP -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to repro: 1. Create a package with a signature and a module which imports it 2. Add `{-# LANGUAGE CPP #-}` to the module Expected result: it works Actual result: {{{ <command line>: unknown package: hole }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15378: Use TcLevels to decide about floating out of implications
by GHC 14 Jul '18

14 Jul '18

#15378: Use TcLevels to decide about floating out of implications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- If we have an implication constraint `forall[3] sk[3]. [W] alpha[2] ~ Maybe b[2]`, GHC ''floats'' the constraint out of the implication. This is necessary to solve this particular wanted, because the implication is at level 3, while the unification variable `alpha` is at level 2; the variable is thus untouchable in the implication. Right now, computing which constraints can float out is done by looking at the free variables of the constraint and comparing against the set of skolem variables bound in the implication, like `sk[3]`, above (among a few other places). However, there is a much easier way: just use the levels. We can look at the Wanted and determine that it can float out because the maximum level in the wanted is a 2, and the implication is level 3. Thus, this ticket is to track that refactoring: use levels, not free variables, in determining what to float out of an implication. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15142: GHC HEAD regression: tcTyVarDetails
by GHC 14 Jul '18

14 Jul '18

#15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This regression prevents the `generic-lens` library from building. Here is a minimized test case: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class ListTuple (tuple :: Type) (as :: [(k, Type)]) where type ListToTuple as :: Type }}} On GHC 8.4.2, this compiles, but on GHC HEAD, it panics: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180511 for x86_64-unknown-linux): tcTyVarDetails co_aWx :: (k_aWt[tau:2] :: *) ~# (* :: *) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #15376: GHC determine illegal kind for standalone deriving with Deriving via
by GHC 14 Jul '18

14 Jul '18

#15376: GHC determine illegal kind for standalone deriving with Deriving via -------------------------------------+------------------------------------- Reporter: | Owner: (none) mizunashi_mana | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- Happy to release GHC 8.6.1-alpha1! I used it to test new extensions, and then I met below errors: {{{ $ ghci-8.6.0.20180627 GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Prelude> :set -XDerivingVia -XStandaloneDeriving Prelude> newtype FunctorWrapped f a = FunctorWrapped (f a) Prelude> deriving via f instance Functor f => Functor (FunctorWrapped f) <interactive>:3:33: error: • Expected kind ‘* -> *’, but ‘f’ has kind ‘*’ • In the first argument of ‘Functor’, namely ‘f’ In the stand-alone deriving instance for ‘Functor f => Functor (FunctorWrapped f)’ <interactive>:3:62: error: • Expected kind ‘* -> *’, but ‘f’ has kind ‘*’ • In the first argument of ‘FunctorWrapped’, namely ‘f’ In the first argument of ‘Functor’, namely ‘(FunctorWrapped f)’ In the stand-alone deriving instance for ‘Functor f => Functor (FunctorWrapped f)’ }}} However, {{{ newtype FunctorWrapped f a = FunctorWrapped (f a) deriving Functor via f }}} is passed through on GHC 8.6.1-alpha1. Is this a bug or my misunderstand? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15377: Cut an STM release
by GHC 14 Jul '18

14 Jul '18

#15377: Cut an STM release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/stm | Version: 8.4.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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15375: GHC.Exts.Heap.getClosureData doesn't return the payload for AP_STACK
by GHC 13 Jul '18

13 Jul '18

#15375: GHC.Exts.Heap.getClosureData doesn't return the payload for AP_STACK -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Runtime | Version: 8.4.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: -------------------------------------+------------------------------------- See Phab:D4955 We used to return the payload, but a stack is a mixture of pointers and non-pointers, so this was bogus. In Phab:D4955 I changed it to ignore the payload, so now at least it doesn't crash, but we don't have any payload info. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 13 Jul '18

13 Jul '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0