November 2017 - ghc-tickets

[GHC] #13790: GHC doesn't reduce type family in kind signature unless its arm is twisted
by GHC 26 Jun '18

26 Jun '18

#13790: GHC doesn't reduce type family in kind signature unless its arm is twisted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code (inspired by Richard's musings [https://github.com/goldfirere/singletons/issues/150#issuecomment-306088297 here]) which typechecks with GHC 8.2.1 or HEAD: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data family Sing (a :: k) data SomeSing (k :: Type) where SomeSing :: Sing (a :: k) -> SomeSing k type family Promote k :: Type class (Promote (Demote k) ~ k) => SingKind (k :: Type) where type Demote k :: Type fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k type family DemoteX (a :: k) :: Demote k type instance DemoteX (a :: Type) = Demote a type instance Promote Type = Type instance SingKind Type where type Demote Type = Type fromSing = error "fromSing Type" toSing = error "toSing Type" ----- data N = Z | S N data instance Sing (z :: N) where SZ :: Sing Z SS :: Sing n -> Sing (S n) type instance Promote N = N instance SingKind N where type Demote N = N fromSing SZ = Z fromSing (SS n) = S (fromSing n) toSing Z = SomeSing SZ toSing (S n) = case toSing n of SomeSing sn -> SomeSing (SS sn) }}} Things get more interesting if you try to add this type instance at the end of this file: {{{#!hs type instance DemoteX (n :: N) = n }}} Now GHC will complain: {{{ GHCi, version 8.2.0.20170522: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:49:34: error: • Expected kind ‘Demote N’, but ‘n’ has kind ‘N’ • In the type ‘n’ In the type instance declaration for ‘DemoteX’ | 49 | type instance DemoteX (n :: N) = n | ^ }}} That error message smells funny, since we do have a type family instance that says `Demote N = N`! In fact, if you use Template Haskell to split up the declarations manually: {{{#!hs ... instance SingKind N where type Demote N = N fromSing SZ = Z fromSing (SS n) = S (fromSing n) toSing Z = SomeSing SZ toSing (S n) = case toSing n of SomeSing sn -> SomeSing (SS sn) $(return []) type instance DemoteX (n :: N) = n }}} Then the file typechecks without issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12769: ghc: internal error: stg_ap_pp_ret
by GHC 22 Jun '18

22 Jun '18

#12769: ghc: internal error: stg_ap_pp_ret ----------------------------------------+---------------------------------- Reporter: kinnla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- appeared when building a project on macOS Sierra: https://github.com/Potregon/while/blob See attached log file (told me to report the bug) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11958: Improved testing of cross-compiler
by GHC 21 Jun '18

21 Jun '18

#11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: task | Status: new Priority: low | Milestone: 8.2.1 Component: Test Suite | Version: 7.10.3 Keywords: cross-compile | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is already possible to build cross compiler eg from x86_64/linux to armhf/linux or arm64/linux, but there is currently no way to run the test suite. However, at least for the host and targets above, it should be possible to run the test executables under the Qemu user space emulation. I know this works, because in my own personal jenkins build instance, I test exactly this by doing (for x86_64/linux to amr64/linux cross): {{{ echo -e 'main :: IO ()\nmain = putStrLn "Hello World"\n' > hello-world.hs inplace/bin/ghc-stage1 hello-world.hs -o hello-world test $(file hello-world | grep -c 'ARM aarch64, version 1') -eq 1 ./hello-world }}} The linux machine I run the above test on is x86_64/linux but has Qemu and `binfmt` stuff set up so that it can run some foreign binaries. For instance, if GHC worked as a Linux to Windows cross-compiler the resulting windows binaries should work under Wine. To get this working, I suspect that just about all the required work is in the build system. Not sure if it might not be better to wait until the Shake based build system is in better shape. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14319: Stuck kind families can lead to lousy error messages
by GHC 21 Jun '18

21 Jun '18

#14319: Stuck kind families can lead to lousy error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeFamilies, TypeInType, ScopedTypeVariables #-} module ArityError where import Data.Kind import GHC.TypeLits import Data.Proxy type family F (s :: Symbol) :: Type type family G (s :: Symbol) :: F s type instance G "Hi" = Maybe }}} This produces the error message {{{#!hs ArityError.hs:10:24: error: • Expecting one more argument to ‘Maybe’ Expected kind ‘F "Hi"’, but ‘Maybe’ has kind ‘* -> *’ • In the type ‘Maybe’ In the type instance declaration for ‘G’ | 10 | type instance G "Hi" = Maybe | ^^^^^ }}} This looks utterly bogus: `F "Hi"` is stuck, so we have no idea what arity it indicates. What I ''think'' is a term level version of this, {{{#!hs f :: forall (s :: Symbol). Proxy s -> F s f _ = Just }}} gives a much less confusing message: {{{ ArityError.hs:14:7: error: • Couldn't match expected type ‘F s’ with actual type ‘a0 -> Maybe a0’ The type variable ‘a0’ is ambiguous • In the expression: Just In an equation for ‘f’: f _ = Just • Relevant bindings include f :: Proxy s -> F s (bound at ArityError.hs:14:1) | 14 | f _ = Just | ^^^^ }}} The fix (I think) is to refrain from reporting arity errors when we don't know enough about the relevant arities. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13724: Clamping of llvm llc to -O1 and -O2
by GHC 21 Jun '18

21 Jun '18

#13724: Clamping of llvm llc to -O1 and -O2 -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (LLVM) | 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 currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`. The reason is that with `-O0`, the naive register allocator can topple over with {{{ Error while trying to spill R1 from class GPR: Cannot scavenge register without an emergency spill slot! }}} and with `-O3` the `llvm::SelectionDAGISel::LowerArguments` may break, when compiling `rts/HeapStackCheck.cmm` with the stage1 ghc. {{{ 0 llc 0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 llc 0x0000000102ae69a6 SignalHandler(int) + 358 2 libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26 3 libsystem_c.dylib 0x00007fffc226498b __vfprintf + 17876 4 llc 0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699 5 llc 0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381 6 llc 0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457 7 llc 0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20 8 llc 0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134 9 llc 0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498 10 llc 0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67 11 llc 0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920 12 llc 0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133 13 llc 0x000000010195bf0b main + 491 14 libdyld.dylib 0x00007fffc21e5235 start + 1 Stack dump: 0. Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"' }}} `opt` and `llc` should respect `-opt_lo` and `-opt_lc`, such that `-opt_lc=-O3` can be used to validate the behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14413: Profiling breaks determinism
by GHC 21 Jun '18

21 Jun '18

#14413: Profiling breaks determinism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: determinism | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking at #5889 I noticed that `CostCentre` currently includes a `Unique` (although it's represented as an `Int` for reasons that aren't relevant here; I change this in Phab:D4148). This unique identifies the cost centre and appears to be derived from the unique of a binder. This presumably breaks determinism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13240: Make it easier to find builds we may want to cancel
by GHC 21 Jun '18

21 Jun '18

#13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Trac & Git | 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: -------------------------------------+------------------------------------- I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples: 1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. 2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific. 3. Only documentation files have changed. Building these on one platform should be sufficient. 4. A differential was closed by a commit. Only the most recent build will be useful, if that. It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13205: Run `validate --slow` during CI at least sometimes.
by GHC 21 Jun '18

21 Jun '18

#13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- Reporter: dobenour | 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: -------------------------------------+------------------------------------- We really should run `validate --slow` at times. It would catch #13204. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10059: :i doesn't work for ~
by GHC 21 Jun '18

21 Jun '18

#10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs Prelude> :set -XTypeOperators Prelude> :i (~) <interactive>:1:2: parse error on input ‘~’ Prelude> :k (~) (~) :: k -> k -> Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14023: Split up glasgow_exts.rst
by GHC 19 Jun '18

19 Jun '18

#14023: Split up glasgow_exts.rst -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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: -------------------------------------+------------------------------------- The `docs/users-guide/glasgow_exts.rst` is crazy large. This makes it difficult to navigate both while editing and reading. It should probably be split up into multiple files along the top-level headings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4