December 2018 - ghc-tickets

[GHC] #10739: Resuscitate the humble ticky-ticky profiler
by GHC 04 Dec '18

04 Dec '18

#10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky ticky- ticky profiler] is known to be quite bit-rotted. Indeed there currently isn't even a definitive list of the counters, much less what they counter and whether they are still accurate. That being said, it can be quite useful and is worth putting effort into bringing back up to grade. There are a few things that need to be done here, 1. Collect a list of the existing counters 2. Work out what they are supposed to be measuring 3. Decide which still have a chance of being useful and accurate 4. ??? 5. Profile! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15814: Orphan Instance Overlap Error Message
by GHC 04 Dec '18

04 Dec '18

#15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 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 working on moving some code around which unfortunately relies on orphan instances. This is the error I get: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} The first instance is the one that I have defined. The second is defined in library code upstream -- great! I want to use that one instead. However, I don't have a clue which module import is providing that instance. It would be *fantastic* if there was an additional line that says which module imported the instance, or brought it into scope. Multiple modules might do this; in this case, reporting any of them would be fine. Eg: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ -- and imported via | 186 | import Cardano.Wallet.API.V1.Swagger.Example | instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ -- and imported via | ??? | this information would literally make my day | • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} I'll have to binary search the import list to try and figure out which module is bringing the instance into scope otherwise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15959: If a type signature is too long to read left-to-right then let it read top-to-bottom.
by GHC 04 Dec '18

04 Dec '18

#15959: If a type signature is too long to read left-to-right then let it read top- to-bottom. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- When pretty printing a type signature that is too long to show in one line, can we please break the lines on the top-level punctuation of the type signature, on {{{::}}}, {{{=>}}} and {{{->}}} as shown in the second listing below? {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} If a type signature is too long to display in one line and read left-to- right then please let it read top-to-bottom. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15935: TYPE is not generated by genprimops
by GHC 04 Dec '18

04 Dec '18

#15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.2 Libraries | Keywords: GHC.Magic | Operating System: Unknown/Multiple TYPE haddock GHC.Prim genprimops | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During validation, GHC.Magic must build without warning, and must also type check with Haddock without warnings. This causes some awkwardness in GHC.Magic (see the comment above the imports regarding genprimops) because TYPE is exported from GHC.Prim and reexported by GHC.Types. We are forced to explicitly import it via GHC.Types (and not from GHC.Prim to avoid an unused import warnings). Importing via GHC.Prim would not type check with Haddock as genprimops doesn't generate TYPE for GHC.Prim. This issue surfaced in patch D5312. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15991: Regression in error message when attempting to let bind an existentially quantified type
by GHC 03 Dec '18

03 Dec '18

#15991: Regression in error message when attempting to let bind an existentially quantified type -------------------------------------+------------------------------------- Reporter: mmailhot | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When attempting to compile the following (invalid) program: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} data Foo = forall a. Foo a main :: IO () main = let Foo x = Foo 1 in return () }}} GHC 8.6.2.0 (and 8.6.1.0, 8.4.1.0) gives the following complicated error message {{{ Test.hs:7:13: error: • Couldn't match expected type ‘p’ with actual type ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: Foo :: forall a. a -> Foo, in a pattern binding at Test.hs:7:9-13 • In the pattern: Foo x In a pattern binding: Foo x = Foo 1 In the expression: let Foo x = Foo 1 in return () | 7 | let Foo x = Foo 1 in | }}} GHC 7.10.1.2 gave a much more helpful and direct error message {{{ Test.hs:7:9: My brain just exploded I can't handle pattern bindings for existential or GADT data constructors. Instead, use a case-expression, or do-notation, to unpack the constructor. In the pattern: Foo x In a pattern binding: Foo x = Foo 1 In the expression: let Foo x = Foo 1 in return () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints
by GHC 03 Dec '18

03 Dec '18

#14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | 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: -------------------------------------+------------------------------------- Add an error message to the compiler when ApplicativeDo desugaring: * requires a Monad constraint when a Functor/Applicative constraint is expected * Adding a lazy pattern match could allow the Functor/Applicative constraint bgamari suggests something like the following message: {{{#!hs ApplicativeDo is enabled yet Monad is required due to irrefutable pattern match; perhaps you want to make the match refutable by adding a ~? }}} Background: In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad constraints when using a strict pattern match (see #13875 for details). While this behavior is a requirement for maintaining the intended semantics of ApplicativeDo, it is both a breaking change, and somewhat unintuitive (see #14249). Adding a message would provide both clarification around the requirement, and provide a simple resolution for the common use case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15760: Preserve parens in TH
by GHC 03 Dec '18

03 Dec '18

#15760: Preserve parens in TH -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.1 Haskell | 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: -------------------------------------+------------------------------------- Template Haskell supports parentheses in its AST. So does GHC. Yet GHC casually discards parentheses when desugaring TH quotes. We should preserve them. I was originally thinking that this could get rid of `Note [Adding parens for splices]` in Convert, but that processing would still be necessary if we are converting TH AST that did not come from a quote. Actually, it gets worse with this change, because we don't want to add ''redundant'' parens. Still, I think preserving parens is the right thing to do here. It also makes it possible for a client to give special meaning to, say, nested parens: Perhaps `process [| f x |]` and `process [| f ((x)) |]` will behave differently. (Idiom brackets, anyone?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15479: Return HsType GhcTc from tc_hs_type
by GHC 03 Dec '18

03 Dec '18

#15479: Return HsType GhcTc from tc_hs_type -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ 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: -------------------------------------+------------------------------------- This is a part of https://ghc.haskell.org/trac/ghc/wiki/Design/TypeRefactor -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15986: Poor error message source location reporting with unsaturated type family
by GHC 03 Dec '18

03 Dec '18

#15986: Poor error message source location reporting with unsaturated type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeErrors | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this program: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where newtype WrapChar f = MkWrapChar (f Char) type family F a type family T a type instance T Int = WrapChar F }}} Then you'll get this error message: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:15: error: • The type family ‘F’ should have 1 argument, but has been given none • In the type instance declaration for ‘T’ | 7 | type instance T Int = WrapChar F | ^ }}} The thing is, the location of that caret is rather unfocused. It's pointing at `T`, but the real culprit is `F`! I know that GHC can do better here because other error messages actually get this right. For instance, if you change the `T Int` instance to this: {{{#!hs type instance T Int = F }}} Then GHC will actually point to `F` in the resulting error message: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:23: error: • Expecting one more argument to ‘F’ Expected a type, but ‘F’ has kind ‘* -> *’ • In the type ‘F’ In the type instance declaration for ‘T’ | 7 | type instance T Int = F | ^ }}} If GHC can point to the right place in the source code in this situation, then it ought to get the earlier situation right as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15980: unpin a mutable byte array
by GHC 03 Dec '18

03 Dec '18

#15980: unpin a mutable byte array -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Sometimes, it necessary to allocate a mutable byte array as pinned. This commonly happens when the mutable byte array will immidiately be handed over to a `safe` FFI routine to be initialized. However, after it has been initialized, it might not be useful for it to be pinned anymore. If it's a little byte array, it may contribute to a fragmented heap. Even if it's large, the fact that the user explicitly asked pin it prohibits it from ever being added to a compact region (pinned bytearrays that were pinned simply because they are over 3KB can be added to compact regions). A workaround for either of these problems is to copy the pinned bytearray into an unpinned byte array afterwards. But that's kind of wasteful. Is it possible to have a primop {{{ unpinMutableByteArray :: MutableByteArray s -> State# s -> State# s }}} After this, the mutable byte array could be moved in memory. This would require `isMutableByteArrayPinned#` to undergo a similar transition as `sizeofMutableByteArray#` (which was superceeded by `getSizeofMutableByteArray#`) underwent. Is this possible? Or are pinned things allocated in a special place that makes unpinning impossible? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4