September 2018 - ghc-tickets

[GHC] #15598: RebindableSyntax with RankNTypes and type class method call yields panic.
by GHC 04 Sep '18

04 Sep '18

#15598: RebindableSyntax with RankNTypes and type class method call yields panic. -------------------------------------+------------------------------------- Reporter: romanb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux RebindableSyntax, RankNTypes | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program in a file `ghc-panic.hs` {{{ {-# LANGUAGE GADTSyntax , RankNTypes , RebindableSyntax #-} import Prelude hiding ((>>=)) data InfDo where InfDo :: String -> (forall a. a -> InfDo) -> InfDo prog :: InfDo prog = do _ <- show (42 :: Int) prog where (>>=) = InfDo main :: IO () main = let x = prog in x `seq` return () }}} when loaded into GHCi yields {{{ λ> main ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): nameModule system $dShow_abfY Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name }}} and separate compilation yields {{{ $ ghc ghc-panic.hs [1 of 1] Compiling Main ( ghc-panic.hs, ghc-panic.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): StgCmmEnv: variable not found $dShow_a1qI local binds for: $tcInfDo $trModule $tcInfDo1_r1th $tcInfDo2_r1tH $trModule1_r1tI $trModule2_r1tJ $trModule3_r1tK $trModule4_r1tL sat_s1E4 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv }}} The problem disappears when either the rank-2 type is removed from `InfDo` or when the call to `show` is replaced by a static string. Besides 8.4.3, also reproduced with 8.6.0.20180714 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15596: When a type application cannot be applied to an identifier due to the absence of an explicit type signature, let the error just say so!
by GHC 03 Sep '18

03 Sep '18

#15596: When a type application cannot be applied to an identifier due to the absence of an explicit type signature, let the error just say so! -------------------------------------+------------------------------------- Reporter: kindaro | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# language TypeApplications #-} module TypeApplicationsErrorMessage where f = (+) g = f @Integer }}} This is what happens when I try to compile it: {{{#!hs % ghc TypeApplicationsErrorMessage.hs [1 of 1] Compiling TypeApplicationsErrorMessage ( TypeApplicationsErrorMessage.hs, TypeApplicationsErrorMessage.o ) TypeApplicationsErrorMessage.hs:6:5: error: • Cannot apply expression of type ‘a0 -> a0 -> a0’ to a visible type argument ‘Integer’ • In the expression: f @Integer In an equation for ‘g’: g = f @Integer | 6 | g = f @Integer | ^^^^^^^^^^ }}} This error is easily fixed by supplying an explicit type signature to `f`. So, perhaps the error message could just say so? I am observing this with `The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180810`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 03 Sep '18

03 Sep '18

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Note that `data A = A !Int` and `newtype A = A Int` have subtly different surface language semantics when they're pattern matched on. What would `case undefined of A _ -> 1` evaluate to? For newtypes, it's `1` whereas for strict data types this would blow up. I guess what I'm saying is: The suggested lowering must preserve `data` semantics and can never behave the same as actual `newtype`s. Semantically, `data` is `data` and `newtype` is `newtype`. It would get rid of the performance implications, though. See this reddit thread for a longer discussion: https://www.reddit.com/r/haskell/comments/6xri4d/whats_the_difference_betwe… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15597: GHC shouting: panic!
by GHC 03 Sep '18

03 Sep '18

#15597: GHC shouting: panic! -------------------------------------+------------------------------------- Reporter: tstr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: TypeInType | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program makes the impossible happen: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} import GHC.Types data Bug :: (f x -> Type) -> Type where Bug :: forall (r::h -> forall x. f x -> Type) (a::f x) . (r::((f x -> Type) -> Type) -> forall x. f x -> Type) Bug a -> Bug (r::f x -> Type) }}} And asked for reporting the error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): piResultTy k_aozeA[tau:1] (x_aozeN[sk:2] |> {co_aozeO}) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:950:35 in ghc:Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15597> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8441: Allow family instances in an hs-boot file
by GHC 03 Sep '18

03 Sep '18

#8441: Allow family instances in an hs-boot file ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compiling an .hs-boot file with a data instance leads to this error: {{{ Illegal family instance in hs-boot file }}} Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance. Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13930: Cabal configure
by GHC 03 Sep '18

03 Sep '18

#13930: Cabal configure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- `cabal configure` apparently has a space leak when compiled with GHC HEAD but not 8.0. It's not clear whether this is really a GHC regression yet, but here it is certainly GHC version-specific. See https://github.com/haskell/cabal/issues/4589 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #15575: Investigate Haskell rewrite of testsuite driver
by GHC 03 Sep '18

03 Sep '18

#15575: Investigate Haskell rewrite of testsuite driver -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Research needed Component: Test Suite | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15363 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the testsuite driver is written in Python. This is a bit of a liability: - Having to program in "not Haskell" might scare away potential contributors here - Even developers who are proficient in Python probably prefer working with Haskell - Managing Python as a dependency poses an additional burden and complicates deployment, setting up dev environments, CI, etc.; especially on Windows. - We miss out on the benefits of type checks and typed programming for a substantial bit of infrastructure - We miss out on a nice dog-fooding opportunity So in order to judge the scope of this task, and define it better, it would be good to investigate a bit: - What would it take to get high-level feature parity with the current solution? - Does the Haskell ecosystem cover the concerns that we would like to address with existing libraries? (Process management, for example) - Can we come up with a smart and frictionless way of migrating all the existing test cases in a reliable automated fashion? - What are risks and unknowns? #15363 is the recent case that sparked this - rather than the proposed patch there, which ports existing Haskell code to Python, we would prefer going in the other direction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15575> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15515: Bogus "No instance" error when type families appear in kinds
by GHC 03 Sep '18

03 Sep '18

#15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- The following code typechecks: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy class C a where c :: Proxy a type family F data D :: F -> Type instance C (D :: F -> Type) where c = undefined }}} However, if we try to actually //use// that `C D` instance, like so: {{{#!hs c' :: Proxy (D :: F -> Type) c' = c @(D :: F -> Type) }}} Then GHC gives a rather flummoxing error message: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:20:6: error: • No instance for (C D) arising from a use of ‘c’ • In the expression: c @(D :: F -> Type) In an equation for ‘c'’: c' = c @(D :: F -> Type) | 20 | c' = c @(D :: F -> Type) | ^^^^^^^^^^^^^^^^^^^ }}} But that error is clearly misleading, as we defined such a `C D` instance directly above it! The use of the type family `F` in the kind of `D` appears to play an important role in this bug. If I change `F` to be a data type (e.g., `data F`), then `c'` is accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #641: Cross platform repeatable RTS
by GHC 03 Sep '18

03 Sep '18

#641: Cross platform repeatable RTS -----------------------------------+----------------------- Reporter: cgibbard@… | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | -----------------------------------+----------------------- Changes (by Krzysztof Gogolewski <krz.gogolewski@…>): * failure: => None/Unknown Comment: In [changeset:"ed789516e201e4fad771e5588da47a62e53b42b8/ghc" ed78951/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ed789516e201e4fad771e5588da47a62e53b42b8" make iToBase62's inner loop stricter in one of its arguments Summary: hadrian's support for dynamic ways is currently broken (see hadrian#641 [1]). The stage 1 GHCs that hadrian produces end up producing bad code for the `iToBase62` function after a few optimisation passes. In the case where `quotRem` returns (overflowError, 0), GHC isn't careful enough to realise q is _|_ and happily inlines, distributes and floats code around until we end up trying to access index `minBound :: Int` of an array of 62 chars, as a result of inlining the definition of `quotRem` for Ints, in particular the minBound branch [2]. I will separately look into reproducing the bad transformation on a small self-contained example and filling a ticket. [1]: https://github.com/snowleopard/hadrian/issues/641 [2]: https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/GHC/Real.hs#l366 Test Plan: fixes hadrian#641 Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: tdammers, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5106 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/641#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15590: Existentials in newtypes
by GHC 01 Sep '18

01 Sep '18

#15590: Existentials in newtypes -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Please allow existential quantification of phantom type arguments in newtypes. {{{ type role A nominal representational phantom -- Or inferred roles. newtype B a b where B :: A a b c -> B a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1