August 2016 - ghc-tickets

[GHC] #8955: Syscall intrinsic
by GHC 18 Aug '16

18 Aug '16

#8955: Syscall intrinsic ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Reddit thread: http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ Mentions there are some nice things that can be done with a syscall intrinsic. Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. Should be easy to implement. llvm backend has `llvm.syscall` already. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #393: functions without implementations
by GHC 18 Aug '16

18 Aug '16

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: | Keywords: newcomer 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 Iceland_jack): Unpolished ideas: use `djinn`, [https://mail.haskell.org/pipermail /haskell-cafe/2015-April/119385.html Exference] or any other [http://www.cis.upenn.edu/~stevez/papers/OZ15.pdf program synthesiser]) to supply the function body {{{#!hs {-# SYNTHESISE id #-} id :: forall a. a -> a }}} would be as if the user had written {{{#!hs id :: forall a. a -> a id x = x }}} Perhaps this could be implemented using plugin + annotations, I'm not familiar with the details: {{{#!hs {-# ANN f Exference #-} f :: Show b => (a -> b) -> [a] -> [String] }}} producing {{{#!hs f :: Show b => (a -> b) -> [a] -> [String] f b = fmap (\g -> show (b g)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12432: TypeInType: open type family application as type family return kind fails to compile
by GHC 17 Aug '16

17 Aug '16

#12432: TypeInType: open type family application as type family return kind fails to compile -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With TypeInType enabled, I can use a closed type family to compute the return kind of a type family from its arguments. But an equivalent open type family used in the same way triggers a compilation failure, as if the relevant instance of that open type family were not considered. (Of course, there may be some subtle prohibition of which I am not aware at the present time.) I will attach a test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 17 Aug '16

17 Aug '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by niteria): It's been a while since my last commit, so I will give a quick status update. Determinism is coming to 8.0.2, Ben Gamari kindly merged all the patches I sent him. Thanks Ben! That's a subset of the patches on this ticket, but a subset that was sufficient during my testing on GHC and Stackage to make the results deterministic (interface file determinism). That said phab:D2288, being a TH change couldn't make it into 8.0.2. Fortunately the packages that tripped up on it have been fixed: https://github.com/aelve/microlens/issues/83, https://github.com/ekmett/lens/issues/669. Props to the maintainers for the lightning fast fix! If you're in a position to test 8.0.2 for determinism before it comes out, any reports would be appreciated. No refunds though! Is this ticket ready to be closed? Not yet, it's still possible to accidentally reintroduce non-determinism in GHC. `Ord Unique` is removed, but `UniqFM` doesn't use it and just gets the underlying integer. More work needs to be done to remove non- deterministic operations on `UniqFM`. I intend to do this work, but currently I shifted my focus to migrating to the soon-to-be GHC 8.0.2 within my company. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 17 Aug '16

17 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've lost context on this. The trac ticket is very long, and I'm no longer sure * What, exactly, is the problem we are trying to solve? * What's the overview of the proposed solution? * How the solution works in detail I wonder whether you might write a wiki page on Literal Strings, to describe how literal strings are handled, at least in your proposal? Are there any tests that check that the problem is indeed solved? I notice that the Phab patch changes `.gitmodules` to point to your repos, which presumably can't be right for a commit to GHC master. Sorry to be dense. Thanks. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 16 Aug '16

16 Aug '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11385: Unify named wildcards in different type applications
by GHC 16 Aug '16

16 Aug '16

#11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple NamedWildCards TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ([https://www.reddit.com/r/haskell/comments/4030lv/unifying_distinct_type_var… motivating post]) I would like to use type application to specialize {{{#!hs Sub :: forall (a :: Constraint) (b :: Constraint). (a => Dict b) -> a :- b Sub @(Ord _a) @(Eq _a) :: forall {a}. (Ord a => Dict (Eq a)) -> Ord a :- Eq a }}} and {{{#!hs map :: forall a b. (a -> b) -> [a] -> [b] map @_a @_a :: forall {a}. (a -> a) -> [a] -> [a] }}} Is there a fundamental reason why named wildcards are not allowed to unify between type applications within the same expression? [https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #named-wildcards Documentation]: > These are called named wildcards. All occurrences of the same named wildcard within one type signature will unify to the same type. I don't know if this is intended. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9498: GHC links against unversioned .so files
by GHC 16 Aug '16

16 Aug '16

#9498: GHC links against unversioned .so files ------------------------------------+-------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Keywords: Debian | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+-------------------------------- Greetings, GHC tries to load unversioned dynamic libraries instead of versioned (i.e. libfoo.so instead of libfoo.so.1.2.3). This is a problem, since Distributions like Debian (I don't know about other distributions) don't include unversioned .SOs in their runtime packages and the unversioned are only available in the -dev packages as a symlink to the verioned ones. This means FFI libraries depend on the -dev packages, even though they don't really need them. It would be nice if GHC would try to load the versioned libraries as well. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #12384: Type family not reduced, again
by GHC 16 Aug '16

16 Aug '16

#12384: Type family not reduced, again -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This one looks similar to #12381, but unfortunately, it does not seem to be fixed in HEAD: {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, FlexibleInstances #-} import GHC.Types type family F (a :: Type) :: Type class C a where type D (a :: Type) :: F a instance (F a ~ Bool) => C a where type D a = True }}} This yields (in 8.0.1 and 8.1.20160709): {{{ Constraint.hs:11:14: error: • Expected kind ‘F a’, but ‘'True’ has kind ‘Bool’ • In the type ‘True’ In the type instance declaration for ‘D’ In the instance declaration for ‘C a’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 15 Aug '16

15 Aug '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: 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 oerjan): `LanO` might, however, be a candidate for being zero width when in a strict field, which could help ''other'' types satisfy the newtype condition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0