February 2019 - ghc-tickets

[GHC] #15800: Overlapping instances error with single instance
by GHC 01 Mar '19

01 Mar '19

#15800: Overlapping instances error with single instance -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleContexts, FlexibleInstances #-} module Bug where class C a b instance C a Int x :: () x = undefined :: C a Int => () }}} {{{ ghc -c Bug.hs Bug.hs:10:18: error: • Overlapping instances for C a0 Int Matching givens (or their superclasses): C a Int bound by an expression type signature: forall a. C a Int => () at Bug.hs:10:18-30 Matching instances: instance C a Int -- Defined at Bug.hs:7:10 (The choice depends on the instantiation of ‘a0’) • In the ambiguity check for an expression type signature To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In an expression type signature: C a Int => () In the expression: undefined :: C a Int => () | 10 | x = undefined :: C a Int => () | ^^^^^^^^^^^^^ }}} The "matching instances" bit of the error messages only lists a single instance. Doesn't it take at least two instances for something to overlap? Also, following the algorithm laid out in the user guide (section "Overlapping Instances"), it appears this program should be accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16020: Hadrian: correctly Install libffi shared object files
by GHC 01 Mar '19

01 Mar '19

#16020: Hadrian: correctly Install libffi shared object files -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.3 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: -------------------------------------+------------------------------------- In Phab:D5423 a hack to correctly install the libffi .so files is implemented. This is a quick and dirty solution to fix the hadrian build. Note [Hadrian: install libffi hack] from that patch and also issue #15837 have more details, but ultimately hadrian should not have a special case for libffi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16373: Strings from symbolVal not simplified at compile time
by GHC 28 Feb '19

28 Feb '19

#16373: Strings from symbolVal not simplified at compile time -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | 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: -------------------------------------+------------------------------------- Compiling {{{#!hs {-# LANGUAGE DataKinds, TypeApplications #-} module Test where import GHC.TypeLits import Data.Proxy testAA :: Bool testAA = symbolVal @"A" Proxy == symbolVal @"A" Proxy testAB :: Bool testAB = symbolVal @"A" Proxy == symbolVal @"B" Proxy testAB' :: Bool testAB' = symbolVal @"A" Proxy == symbolVal @"B" Proxy }}} with {{{ ghc -O -ddump-simpl -dsuppress-all Test.hs }}} yields: {{{ -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} testAB'2 testAB'2 = "B"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} testAB'1 testAB'1 = unpackCString# testAB'2 -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} testAA2 testAA2 = "A"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} testAA1 testAA1 = unpackCString# testAA2 -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} testAB' testAB' = eqString testAA1 testAB'1 -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} testAB testAB = testAB' -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} testAA testAA = eqString testAA1 testAA1 }}} Furthermore, removing the type signatures for ''either'' testAB or testAB' makes ''both'' simplify to False! I would expect all three definitions to simplify to True or False, independently of the presence of type signatures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14109: GHC matches -- as a varsym when lexing a qvarsym
by GHC 28 Feb '19

28 Feb '19

#14109: GHC matches -- as a varsym when lexing a qvarsym -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems only to exclude the line comment marker `--` when lexing a varsym and not a qvarsym. This can be observed in the following code {{{ module Demo where x Demo.-- y = (x,y) }}} Generating this surprising error message {{{ /Users/emertens/Desktop/Demo.hs:3:3: error: Qualified name in binding position: Demo.-- }}} and excludes this definition perhaps? {{{ example f = Just.-- comment f }}} Which might either have lexed as `Just` `.` `-- comment`, or it might have lexed as `Just.-` `-`, but it probably shouldn't be the case that it's a qvarsym. At a minimum, the Haskell Report specifically excludes `--` from the varsym rule, so it can't support the qvarsym rule match that it is now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16355: Save CI performance metrics on windows jobs
by GHC 28 Feb '19

28 Feb '19

#16355: Save CI performance metrics on windows jobs -------------------------------------+------------------------------------- Reporter: davide | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Keywords: git notes ci | Operating System: Windows performance test | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- MR !294 enabled saving and pushing of CI performance metrics for all osx and linux CI jobs. Now do the same for the windows jobs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16355> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9121: Presence of dyn_o files not checked? upon recompilation
by GHC 28 Feb '19

28 Feb '19

#9121: Presence of dyn_o files not checked? upon recompilation ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I interrupt a compilation (initiated with cabal), and then recompile (with cabal), it can happen that gcc fails with missing .dyn_o file. I have "shared:True" in my .cabal/config file. [I can of course do cabal clean to work around, but since a full recompilation is about 10 min, I try to avoid this.] time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [239 of 273] Compiling Agda.TypeChecking.Conversion ( src/full/Agda/TypeChecking/Conversion.hs, dist/build/Agda/TypeChecking/Conversion.o ) [Agda.Syntax.Translation.InternalToAbstract changed] ^Cmake: *** [install-bin] Interrupt time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [273 of 273] Compiling Agda.Main ( src/full/Agda/Main.hs, dist/build/Agda/Main.o ) [Agda.Compiler.Epic.Compiler changed] gcc: error: dist/build/Agda/TypeChecking/Conversion.dyn_o: No such file or directory Failed to install Agda-2.3.3 cabal: Error: some packages failed to install: Agda-2.3.3 failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16371: GHC should be more forgiving with visible dependent quantification in visible type applications
by GHC 27 Feb '19

27 Feb '19

#16371: GHC should be more forgiving with visible dependent quantification in visible type applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 (Type checker) | Keywords: | Operating System: Unknown/Multiple VisibleDependentQuantification | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC HEAD currently rejects the following code: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Kind import Data.Proxy f :: forall k a. Proxy a f = Proxy g :: forall (a :: forall x -> x -> Type). Proxy a g = f @(forall x -> x -> Type) @a }}} {{{ GHCi, version 8.9.20190227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:14:6: error: • Illegal visible, dependent quantification in the type of a term: forall x -> x -> * (GHC does not yet support this) • In the type signature: g :: forall (a :: forall x -> x -> Type). Proxy a | 14 | g :: forall (a :: forall x -> x -> Type). Proxy a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But GHC is being too conservative here. `forall x -> x -> *` //isn't// the type of a term here, but rather the kind of a type variable, and it's perfectly admissible to use visible dependent quantification in such a scenario. The immediate reason that this happens is because of this code: {{{#!hs vdqAllowed (TypeAppCtxt {}) = False }}} Unfortunately, fixing this bug isn't as simply as changing `False` to `True`. If you do that, then GHC becomes //too// forgiving and allows things like this: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} lol :: forall a. a lol = undefined t2 = lol @(forall a -> a -> a) }}} Here, visible dependent quantification is leaking into the type of a term, which we definitely don't want to happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family
by GHC 27 Feb '19

27 Feb '19

#15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind type KindOf1 (a :: k) = k type family KindOf2 (a :: k) :: Type where KindOf2 (a :: k) = k data A (a :: Type) :: a -> Type type family Apply1 (f :: KindOf1 A) (a :: Type) (x :: a) :: Type where Apply1 f a x = f a x }}} `Apply1` kind-checks, which is just peachy. Note that `Apply1` uses `KindOf1`, which is a type synonym. Suppose I wanted to swap out `KindOf1` for `KindOf2`, which is (seemingly) an equivalent type family. I can define this: {{{#!hs type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) (a :: Type) (x :: a) :: Type where Apply2 f a x = f a x }}} However, GHC rejects this! {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:25:10: error: • Expecting two more arguments to ‘f’ Expected kind ‘KindOf2 A’, but ‘f’ has kind ‘* -> a -> *’ • In the first argument of ‘Apply2’, namely ‘f’ In the type family declaration for ‘Apply2’ | 25 | Apply2 f a x = f a x | ^ }}} I find this quite surprising, since I would have expected `KindOf1` and `KindOf2` to be functionally equivalent. Even providing explicit `forall`s does not make it kind-check: {{{#!hs type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) (a :: Type) (x :: a) :: Type where forall (f :: KindOf2 A) (a :: Type) (x :: a). Apply2 f a x = f a x }}} Although the error message does change a bit: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:26:20: error: • Expected kind ‘* -> a -> *’, but ‘f’ has kind ‘KindOf2 A’ • In the type ‘f a x’ In the type family declaration for ‘Apply2’ | 26 | Apply2 f a x = f a x | ^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14419: Check kinds for ambiguity
by GHC 27 Feb '19

27 Feb '19

#14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- GHC does an ambiguity check on types. It should also do the same for kinds. Here is a program that should be rejected: {{{#!hs type family F a data T :: F a -> Type }}} `T`'s kind is ambiguous, and any occurrence of `T` will be rejected. Instead of rejecting usage sites, let's just reject the definition site. This check would be disabled by `AllowAmbiguousTypes`. Happily, I think the implementation should be easy, and that the current algorithm to check for ambiguous types should work for kinds, too. After all, types and kinds are the same these days. This was inspired by #14203, but no need to read that ticket to understand this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13408: Consider inferring a higher-rank kind for type synonyms
by GHC 27 Feb '19

27 Feb '19

#13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | 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 terms, a definition comprising one non-recursive equation may have a higher-rank type inferred. For example: {{{#!hs f :: (forall a. a -> a -> a) -> Int f z = z 0 1 g = f }}} `g` gets an inferred type equal to `f`'s. However, this fails at the type level: {{{#!hs type F (z :: forall a. a -> a -> a) = z 0 1 type G = F }}} If anything is strange here, it's that the term-level definition is accepted. GHC should not be in the business of inferring higher-rank types. But there is an exception for definitions comprising one non- recursive equation. This ticket proposes expanding this behavior to the type level, allowing `G` to be accepted. This is spun off from #13399, but is not tightly coupled to that ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12