- ghc-tickets - Haskell.org

[GHC] #14993: QuantifiedConstraints and principal types
by GHC 04 Apr '18

04 Apr '18

#14993: QuantifiedConstraints and principal types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is not a bug but I am trying to understand the ~~implication~~ significance of `-XQuantifiedConstraints`. [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp- outsidein.pdf OutsideIn(X)] (section **2.4**) tells us `test` actually has a principle type when we have implication constraints) {{{#!hs data T :: Type -> Type where T1 :: Int -> T Bool T2 :: T a test :: (a~Bool => b~Bool) => T a -> b -> b test (T1 n) _ = n > 0 test T2 r = r }}} that subsumes {{{#!hs test1 :: T a -> a -> a test1 = test test2 :: T a -> Bool -> Bool test2 = test }}} Now that we have `-XQuantifiedConstraints` does this change the story at all, if not you can close this.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

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

04 Apr '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I just hit this bug on x86_64 with GHC-8.2.2. It's a large program, so I can't provide an example, but this is still a problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15001: Add strict product field demands to lambda binders
by GHC 04 Apr '18

04 Apr '18

#15001: Add strict product field demands to lambda binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.5 Keywords: DmdAnal | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D4244 | Wiki Page: -------------------------------------+------------------------------------- This is a follow-up on the first improvement in [Phab:D4244#126311]. Consider the following two functions with identical semantics: {{{ module Foo where {-# LANGUAGE BangPatterns #-} data Complex a = !a :+ !a foo :: Complex Double -> Int -> Complex Double foo !x 0 = x foo (a :+ b) _ = b :+ a bar :: Complex Double -> Int -> Complex Double bar x 0 = x bar (a :+ b) _ = b :+ a }}} In the corresponding simplified Core, `x` gets strictness `S(SS)` for `foo`, but only `S` for `bar`. We could do better by looking at `x`s type and see that its a product type with strict fields. This is because currently only case binders get [https://github.com/ghc/ghc/blob/72b5f649ede82ab3bb429aa72ee1c572f415b0eb/co… special treatment] for strict product fields through `addDataConStrictness`. This ticket tracks if the same is worthwhile for lambda binders, as in `bar` above. Note that intuitively, this shouldn't make any difference because when we eventually unleash an `S` demand on a `Complex` constructor, we add `seqDmd` on strict fields anyway, amounting to `S(SS)`. So this is only a matter of recording things early because some parts of the analysis code might not be smart enough to add strict field demands by themselves. Also note that this doesn't touch impliciations on usage analysis at all, where unleashing the same `seqDmd` twice might mean we accidentally make some product field lose its single-entrieness. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12938: Polykinded associated type family rejected on false pretenses
by GHC 04 Apr '18

04 Apr '18

#12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- If I say {{{ class HasRep a where type Rep a :: TYPE r }}} I get {{{ • Kind variable ‘r’ is implicitly bound in datatype ‘Rep’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: a • In the class declaration for ‘HasRep’ }}} This definition should be accepted, though, as `r` is just an invisible parameter to the associated type family. (I don't know how ''useful'' this is, but it's not bogus.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12742: Instantiation of invisible type family arguments is too eager
by GHC 04 Apr '18

04 Apr '18

#12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This module looks, to me, like it should be accepted: {{{ {-# LANGUAGE TypeInType, RankNTypes, TypeFamilies #-} module Bug where import Data.Kind type family F :: forall k2. (k1, k2) data T :: (forall k2. (Bool, k2)) -> Type type S = T F }}} But it's not. The problem is that `TcHsType.handle_tyfams` eagerly instantiates ''all'' invisible arguments to a type family at every occurrence. Instead, it should instantiate only those that are counted in the TF's arity -- that is, those "before the colon". Will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14764: Make $! representation-polymorphic
by GHC 04 Apr '18

04 Apr '18

#14764: Make $! representation-polymorphic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4382 | Wiki Page: -------------------------------------+------------------------------------- Currently, {{{#!hs ($) :: forall r a (b :: TYPE r). (a -> b) -> a -> b }}} but {{{#!hs ($!) :: (a -> b) -> a -> b }}} It seems fairly obvious that we should generalize `($!)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14764> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14795: Data type return kinds don't obey the forall-or-nothing rule
by GHC 04 Apr '18

04 Apr '18

#14795: Data type return kinds don't obey the forall-or-nothing rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally noticed [https://github.com/ghc-proposals/ghc- proposals/pull/103#issuecomment-364562974 here]. GHC accepts this: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} import Data.Kind data Foo :: forall a. a -> b -> Type where MkFoo :: a -> Foo a b }}} Despite the fact that `Foo`'s return kind is headed by an explicit `forall` which does not quantify `b`. The users' guide doesn't explicitly indicate that the `forall`-or-nothing rule should apply to data type return kinds, but goldfirere believes that not doing so is an [https://github.com/ghc-proposals/ghc- proposals/pull/103#issuecomment-364670215 inconsistent design], so I'm opening this ticket to track this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13845: Runtime linker too eagerly checks for symbol names
by GHC 04 Apr '18

04 Apr '18

#13845: Runtime linker too eagerly checks for symbol names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | 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 discovered this bug in https://github.com/haskell- foundation/foundation/issues/326. Take this file: {{{#!hs module Main (main) where foreign import ccall "notAThing" notAThing :: IO () main :: IO () main = putStrLn "Hello, World!" }}} Compiling and running this file works without issue. But if you try to use the runtime linker, things go haywire: {{{ $ C:\Users\RyanGlScott\Software\ghc\inplace\bin\runghc Bug.hs ghc-stage2.exe: ^^ Could not load 'notAThing', dependency unresolved. See top entry above. Bug.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: notAThing This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} This isn't just limited to Windows, since the same thing happens on Linux. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13845> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15000: Add a linter for debug information (-g)
by GHC 04 Apr '18

04 Apr '18

#15000: Add a linter for debug information (-g) -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are some sanity checks we can do. For example if you see following Cmm: {{{ unwind Sp = Sp + 16 Sp = Sp + 16 unwind Sp = Sp + 64 }}} You can tell that it's wrong because it's clear how `Sp` changed between the two unwind points. I think this would fit well with the Cmm linter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13330: forkIO has inconsistent behavior under optimization
by GHC 04 Apr '18

04 Apr '18

#13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Troubleshooting the T4030 failure in SimonPJ's early-inline branch, Reid and I discovered that the problem showed up when the argument to `forkIO` was obviously bottom. He came up with a tiny test case that fails without Simon's changes: {{{#!hs main = forkIO undefined >> threadDelay 1000000 }}} It looks like the trouble is in the definition of `forkIO`: {{{#!hs forkIO :: IO () -> IO ThreadId forkIO action = IO $ \ s -> case (fork# action_plus s) of (# s1, tid #) -> (# s1, ThreadId tid #) where action_plus = catchException action childHandler }}} This seems to run into the trouble with `catchException` and strictness explained in `GHC.IO`. It would appear that the conservative fix would be to replace `catchException` with `catch`. Personally, I find it a bit surprising that `forkIO` doesn't force its `IO` argument before forking, but changing that behavior could break working code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22