January 2016 - ghc-tickets

[GHC] #11440: GHC.Prim does not export Constraint
by GHC 20 Jan '16

20 Jan '16

#11440: GHC.Prim does not export Constraint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 code from the `effect-monad` library worked in ghc-7.10, but fails with ghc-8.0.1-rc1: {{{ {-# LANGUAGE TypeFamilies, ConstraintKinds, PolyKinds #-} module Control.Effect.Cond where import GHC.Prim class Cond (m :: k -> * -> *) where type AltInv m (s :: k) (t :: k) :: Constraint }}} It seems one now needs to import `Constraint` from `GHC.Exts`. This should be mentioned in the migration guide (https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0) together with any other breaking changes there might be from the kind equalities patch (6746549772c5cc0ac66c0fce562f297f4d4b80a2). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11440> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10581: Recommend ScopedTypeVariables
by GHC 20 Jan '16

20 Jan '16

#10581: Recommend ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The !ScopedTypeVariables extension is one of the few that doesn't recommend itself when it should be used. I recognize that this may be hard to do, but here is a strawman proposal: Always behave as if !ScopedTypeVariables is on at binding sites for type variables (in an annotation with `forall`). Then, at ''occurrences'' of type variables, check if the extension is on. If a type variable is in scope but the extension is off, remember that the user probably wants the extension, but then rename the type variable occurrence away from the in- scope one. If a type error ensues, we've remembered that the lack of !ScopedTypeVariables may be to blame, and we recommend turning it on. There may be better approaches, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11438: Code does not compile without ScopedTypeVariables
by GHC 20 Jan '16

20 Jan '16

#11438: Code does not compile without ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Feel free to change the summary, I have no idea how to summarize this issue. The code below fails to compile with `Couldn't match type A with B` and `The function X is applied to one argument, but its type Y has none` and some more (full output is attached below the code). However, simply enabling a language feature (`ScopedTypeVariable`) makes the code compile. If this is not a bug in the compiler then the message should be improved, because nothing in it points to the solution. I always thought of ScopedTypeVariables as allowing me to sprinkle `:: T` throughout the code, in more places than GHC would normally allow. I did not expect that merely enabling this language feature without any other changes in the source code would have any effect on the output. Dependencies: servant, servant-server {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeOperators #-} -- {-# LANGUAGE ScopedTypeVariables #-} module Main where import Data.Proxy import Servant.API import Servant.Server data Credentials = Credential !String instance (HasServer sublayout) => HasServer (Credentials :> sublayout) where type ServerT (Credentials :> sublayout) m = Credentials -> ServerT sublayout m route Proxy subserver request respond = do let mbSessionIdString = lookup "cookie" [("cookie", "session id")] mbCredentials = fmap Credential mbSessionIdString case mbCredentials of Nothing -> error "No credentials supplied" Just cred -> route (Proxy :: Proxy sublayout) (subserver cred) request respond }}} {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:30:60: Couldn't match type ‘ServerT sublayout (either-4.4.1:Control.Monad.Trans.Either.EitherT ServantErr IO)’ with ‘ServerT layout0 (either-4.4.1:Control.Monad.Trans.Either.EitherT ServantErr IO)’ NB: ‘ServerT’ is a type function, and may not be injective The type variable ‘layout0’ is ambiguous Expected type: Credentials -> Server layout0 Actual type: ServerT (Credentials :> sublayout) (either-4.4.1:Control.Monad.Trans.Either.EitherT ServantErr IO) Relevant bindings include subserver :: Server (Credentials :> sublayout) (bound at Bug.hs:24:17) route :: Proxy (Credentials :> sublayout) -> Server (Credentials :> sublayout) -> Servant.Server.Internal.RoutingApplication (bound at Bug.hs:24:5) The function ‘subserver’ is applied to one argument, but its type ‘Server (Credentials :> sublayout)’ has none In the second argument of ‘route’, namely ‘(subserver cred)’ In the expression: route (Proxy :: Proxy sublayout) (subserver cred) request respond Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #1316: add warning for local type signatures that use the same type variable names as outer type signatures
by GHC 20 Jan '16

20 Jan '16

#1316: add warning for local type signatures that use the same type variable names as outer type signatures -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11438 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11438 Comment: Closing as a duplicate of #9244, which has a more complete test case, and suggestions for how to implement this. Also reported as #11438. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1316#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11437: Don't put static (version-based) feature gates in compilerInfo
by GHC 20 Jan '16

20 Jan '16

#11437: Don't put static (version-based) feature gates in compilerInfo -------------------------------------+------------------------------------- Reporter: ezyang | 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: -------------------------------------+------------------------------------- It started when someone added `("Support parallel --make", "YES"),`, and then ballooned to a bit more when I added a few more feature gates. I think it's probably wrong for GHC to put feature gates in this structure which are always on or off; Cabal can just version test GHC for appropriate information. (The one benefit of using a feature gate is when you're running a development version of GHC and Cabal, and there is a breakpoint without a version change when a feature is supported). If people agree, we should remove these, and change Cabal to version test to determine if these features are available. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 19 Jan '16

19 Jan '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:5 awson]: > I have fully working `-split-sections` on Windows. That's awesome! Thank you for working on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2988: Improve float-in
by GHC 19 Jan '16

19 Jan '16

#2988: Improve float-in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If you're taking this on, see also #11197, which will likely be fixed by improvements to floating-in. I don't think either of these bugs is dependent on the other exactly, but it would probably be easy to fix them both at the same time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2988#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 19 Jan '16

19 Jan '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I have fully working `-split-sections` on Windows. To make it possible quite recently I've fixed [https://ghc.haskell.org/trac/ghc/ticket/11388 a blocker bug in GHC] (thanks to Phyx for putting it in). But also we need the very latest binutils because of [https://sourceware.org/bugzilla/show_bug.cgi?id=19440 the bug in binutils] I've helped to fix just recently. And the final thing to make it all work are correct linker scripts (generated from the single `pep.sc` template), which solve [https://sourceware.org/bugzilla/show_bug.cgi?id=19254 section merging problem]. I've incorporated it in my own patched version of binutils but I still didn't propose the corresponding patch to upstream binutils. I have no much spare time at the moment, and this patch also contains an extra bugfix for current binutils, thus some extra work is required here, but if the need is urgent I'll try to wrap it in coming days. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 19 Jan '16

19 Jan '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1800 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 19 Jan '16

19 Jan '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by olsner): > So on ELF platforms -split-sections should be ready to replace -split- objs; further testing and investigation is necessary on Windows and OS X. OS X should just use the built-in subsection support. For non-Linux ELF platforms, an issue is that `--gc-sections` (under that name) is only available from GNU ld, other linkers might not have it or might call it something else. That means dropping `-split-objs` probably would leave some platforms without dead-code stripping at all. It should be good to go with GNU ld on non-Windows though. And for unixes without GNU ld we could get configure to check if the linker has something like `--gc-sections` and how to activate it. (Looks like e.g. Solaris has a `-z discard-unused=sections` flag.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0