December 2015 - ghc-tickets

Re: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database
by GHC 06 Dec '15

06 Dec '15

#6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: sibi Type: feature request | Status: patch Priority: normal | Milestone: Component: ghc-pkg | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10785 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D1575 -------------------------------------+------------------------------------- Changes (by sibi): * status: new => patch * differential: => https://phabricator.haskell.org/D1575 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6119#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7275: Give more detailed information about PINNED data in a heap profile
by GHC 06 Dec '15

06 Dec '15

#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.6.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: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7275#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database
by GHC 05 Dec '15

05 Dec '15

#6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: sibi Type: feature request | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10785 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sibi): * owner: => sibi -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6119#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9706: New block-structured heap organization for 64-bit
by GHC 05 Dec '15

05 Dec '15

#9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was having some discussion about GHC's block structured heap with Sergio Benitez and Adam Belay, and during the discussion it was suggested that the way GHC manages the block structured heap is suboptimal when we're on 64-bit architectures. At the moment, we allocate memory from the operating system per-megablock, storing metadata in the very first megablock. We have to do this because, on 32-bit, we can't generally be too picky about what address our memory ends up living. On 64-bits, we have a lot more flexibility. Here is the proposal: 1. Statically decide on a maximum heap size in a power of two. 2. Next, probe for some appropriately aligned chunk of available virtual address space for this. On POSIX, we can mmap /dev/null using PROT_NONE and MAP_NORESERVE. On Windows, we can use VirtualAlloc with MEM_RESERVE. (There are few other runtimes which do this trick, including GCC Go.) 3. Divide this region into blocks as before. The maximum heap size is now the megablock size, and the block size is still the same as before. Masking to find the block descriptor works as before. 4. To allocate, we keep track of the high-watermark, and mmap in 1MB pages as they are requested. We also keep track of how much metadata we need, and mmap extra pages to store metadata as necessary. We still want to request memory from the operating system in conveniently sized chunks, but we can now abolish the notion of a megablock and the megablock allocator, and work purely with block coalescing. Additionally, the recorded heap location means that we can check if a pointer is HEAP_ALLOCED using a mask and equality check, solving #8199. What do people think? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error
by GHC 04 Dec '15

04 Dec '15

#11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10846 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems to forget about in-scope implicit parameters when there's a hole in the type signature. Given {{{#!haskell {-# LANGUAGE ImplicitParams, PartialTypeSignatures #-} module Bad where f1 :: (?loc :: Int, _) => Int f1 = ?loc f2 :: (?loc :: Int) => _ f2 = ?loc }}} GHC incorrectly reports the following errors. {{{ % ghc -fforce-recomp Bad.hs [1 of 1] Compiling Bad ( Bad.hs, Bad.o ) Bad.hs:8:6: Unbound implicit parameter (?loc::Int) arising from a use of implicit parameter ‘?loc’ In the expression: ?loc In an equation for ‘f1’: f1 = ?loc Bad.hs:11:1: Occurs check: cannot construct the infinite type: _ ~ (?loc::Int) => _ When checking that ‘f2’ has the specified type f2 :: (?loc::Int) => _ Probable cause: the inferred type is ambiguous Bad.hs:11:6: Unbound implicit parameter (?loc::_) arising from a use of implicit parameter ‘?loc’ Relevant bindings include f2 :: _ (bound at Bad.hs:11:1) In the expression: ?loc In an equation for ‘f2’: f2 = ?loc }}} `?loc` is very clearly bound by both `f1` and `f2`'s signature. `f2` additionally reports what looks to me to be a bogus occurs-check error; we know from the theta that `?loc :: Int` so the hole should be solved for `Int`. I suspect this is all related to the fact that PartialTypeSignatures triggers `tcPolyInfer` instead of `tcPolyCheck`. I think this is the same underlying bug as #10846. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11144: Custom type errors need tidying
by GHC 04 Dec '15

04 Dec '15

#11144: Custom type errors need tidying -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 an excerpt from `testsuite/tests/typecheck/should_fail/CustomTypeErrors02.stderr`: {{{ CustomTypeErrors02.hs:17:1: error: The type 'a_aES -> a_aES' cannot be represented as an integer. When checking that ‘err’ has the inferred type err :: (TypeError ...) }}} We should tidy these types before printing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 04 Dec '15

04 Dec '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <bnitka@…>): In [changeset:"5b2b7e338c822c34f86e8bd3ff442a979711d1fe/ghc" 5b2b7e33/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b2b7e338c822c34f86e8bd3ff442a979711d1fe" Make callToPats deterministic in SpecConstr This fixes a non-determinism bug where where depending on the order of uniques allocated, the specialized workers would have different order of arguments. Compare: ``` $s$wgo_s1CN :: Int# -> Int -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s1CN = \ (sc_s1CI :: Int#) (sc_s1CJ :: Int) -> case tagToEnum# @ Bool (<=# sc_s1CI 0#) of _ [Occ=Dead] { False -> $wgo_s1BU (Just @ Int (I# (-# sc_s1CI 1#))) (Just @ Int sc_s1CJ); True -> 0# } ``` vs ``` $s$wgo_s18mTj :: Int -> Int# -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s18mTj = \ (sc_s18mTn :: Int) (sc_s18mTo :: Int#) -> case tagToEnum# @ Bool (<=# sc_s18mTo 0#) of _ [Occ=Dead] { False -> $wgo_s18mUc (Just @ Int (I# (-# sc_s18mTo 1#))) (Just @ Int sc_s18mTn); True -> 0# } ``` Test Plan: I've added a new testcase ./validate Reviewers: simonmar, simonpj, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1508 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck
by GHC 03 Dec '15

03 Dec '15

#11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- I wanted to see what error message might result from adding `join` to `Monad` and trying to derive it via `GeneralizedNewtypeDeriving`, so I used this code to simulate it: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module CoerceJoin where import qualified Control.Monad (join) import Data.Coerce (coerce) class MyMonad m where join :: m (m a) -> m a instance MyMonad Maybe where join = Control.Monad.join newtype MyMaybe a = MyMaybe (Maybe a) deriving MyMonad }}} To my surprise, this actually compiles: {{{ ==================== Derived instances ==================== Derived instances: instance CoerceJoin.MyMonad CoerceJoin.MyMaybe where CoerceJoin.join = GHC.Prim.coerce (CoerceJoin.join :: GHC.Base.Maybe (GHC.Base.Maybe a_axs) -> GHC.Base.Maybe a_axs) :: forall (a_axs :: *). CoerceJoin.MyMaybe (CoerceJoin.MyMaybe a_axs) -> CoerceJoin.MyMaybe a_axs Generic representation: Generated datatypes for meta-information: Representation types: }}} That seemed really odd, given my understanding of roles, so I tried to implement this instance manually: {{{#!hs newtype MyMaybe a = MyMaybe (Maybe a) instance MyMonad MyMaybe where join = coerce (join :: Maybe (Maybe a) -> Maybe a) :: MyMaybe (MyMaybe a) -> MyMaybe a }}} And now GHC will reject it: {{{ CoerceJoin.hs:18:10: Couldn't match representation of type `a0' with that of `a1' `a1' is a rigid type variable bound by an expression type signature: MyMaybe (MyMaybe a1) -> MyMaybe a1 at CoerceJoin.hs:18:10 arising from trying to show that the representations of `Maybe (Maybe a0) -> Maybe a0' and `MyMaybe (MyMaybe a1) -> MyMaybe a1' are the same Relevant role signatures: type role Maybe representational type role MyMaybe representational In the expression: coerce (join :: Maybe (Maybe a) -> Maybe a) :: MyMaybe (MyMaybe a) -> MyMaybe a In an equation for `join': join = coerce (join :: Maybe (Maybe a) -> Maybe a) :: MyMaybe (MyMaybe a) -> MyMaybe a In the instance declaration for `MyMonad MyMaybe' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 03 Dec '15

03 Dec '15

#7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't happen for 8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
by GHC 03 Dec '15

03 Dec '15

#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------------+------------------------------------- Reporter: AntoineLatter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ekmett (added) * milestone: 8.0.1 => 8.2.1 Old description: > When trying to use the custom handle infrastructure, hGetContents fails > like so: > > *** Exception: ToDo: hGetBuf > > This exception occurs twice in GHC.IO.Handle.Text > > The handle implementation I'm using is attached. > > It would be neat if I could pass along some witness that my device > implements RawDevice, then we could just run the same code that we use > for file-descriptors. But I'd be happy enough with a general solution, as > I just plan to use this for testing. New description: When trying to use the custom handle infrastructure, `hGetContents` fails like so: {{{ *** Exception: ToDo: hGetBuf }}} This exception occurs twice in `GHC.IO.Handle.Text` The handle implementation I'm using is attached. It would be neat if I could pass along some witness that my device implements `RawDevice`, then we could just run the same code that we use for file-descriptors. But I'd be happy enough with a general solution, as I just plan to use this for testing. -- Comment: This won't be happening for 8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4144#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0