August 2015 - ghc-tickets

[GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install
by GHC 26 Aug '15

26 Aug '15

#9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: clang | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Installing GHC Difficulty: Moderate (less | failed than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- 1) build GHC is built on a machine with clang -- project.mk ends up with the macro CC_CLANG_BACKEND=1 2) make binary-dist on that machine 3) bring that bindist to a machine that doesn't use clang 4) unpack the bindist, ./configure, make install This error ensues: cc1: error: unrecognized command line option "-Wno-invalid-pp-token" cc1: error: unrecognized command line option "-Wno-unicode" The problem rests in that there is on gcc invocation during that make install: /usr/bin/gcc -E ... rts/package.conf.in -o rts/dist/package.conf.install.raw This call is picking up arguments from RAWCPP_FLAGS, set in mk/config.mk, based on CC_CLANG_BACKEND, set in mk/project.mk... which was computed at build time. carter has hypothesized that adding the macro FP_CC_LLVM_BACKEND to distrib/configure.ac.in might fix this. In theory that will cause the config file that is bunded into the bindist to recompute the CC_CLANG_BACKEND flag at dist config time. However, this may not work because the only file that emits CC_CLANG_BACKEND is project.mk and that doesn't seem to get re-written during dist time config. -- so something else will be needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1830: Automatic derivation of Lift
by GHC 26 Aug '15

26 Aug '15

#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | 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 Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by RyanGlScott): According to [http://packdeps.haskellers.com/reverse/th-lift packdeps], 32 libraries immediately depend on `th-lift`. Doing a grep of [https://github.com/bitemyapp/hackage-packages hackage-packages] for files that contain both {{{Language.Haskell.TH.Syntax}}} and {{{instance Lift }}} reveals that these additional libraries define their own {{{Lift}}} instances: {{{ persistent-template shakespeare instant-generics yesod-core sqlite-simple-typed generic-deriving Euterpea regular mysql-simple-typed cake3 lighttpd-conf postgresql-simple-typed type pcre-heavy myTestlll multirec-alt-deriver yesod-routes type-level-tf debian vimus named-records module-management Contract grammar-combinators groundhog-th api-tools Webrexp Webrexp type-level web-routes-quasi monad-logger QuasiText ta logging-facade }}} This obviously isn't scientifically rigorous, as there is a chance that the {{{instance Lift}}} could be using some other {{{Lift}}}, or that the {{{Lift}}} instances in those packages wouldn't be derivable in the first place. But this at least gives an approximation of how much impact {{{deriving Lift}}} might have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10794: Extension request: "where" clauses in type signatures
by GHC 26 Aug '15

26 Aug '15

#10794: Extension request: "where" clauses in type signatures -------------------------------------+------------------------------------- Reporter: danso | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Some type signatures could be simplified by separating certain elements, either because they are lengthy and can be expressed simpler, to better express intention, or because they are repetitive. A "WhereSignatures" extension would allow for type signatures like the following: {{{#!hs fold :: f -> [a] -> a where f :: a -> a -> a -- expresses intention more clearly than: fold :: (a -> a -> a) -> [a] -> a union :: a -> a -> a where a :: Map.Map k v -- much shorter/more readable than: union :: Map.Map k v -> Map.Map k v -> Map.Map k v }}} Or maybe even: {{{#!hs fmap :: (a -> b) -> f a -> f b where (Functor f) -- arguably prettier than: fmap :: (Functor f) => (a -> b) -> f a -> f b }}} This minor syntactic sugar is essentially equivalent to local "type" definitions, which provides an advantage of making the type's purpose more clear. This seems like a natural development on what the type checker can do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10794> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1830: Automatic derivation of Lift
by GHC 26 Aug '15

26 Aug '15

#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | 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 Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by simonpj): I'm not dead set against this (adding new auto-derived classes doesn't interact with anything), but it does impose a little extra maintenance burden to keep it all working and you can get nearly the same behaviour with a (perhaps enhance) `th-lift` library. It would seem more persuasive if there was more than one advocate for it. Is there a large constituency of TH users who will benefit from this? Data from Hackage might be illuminating... how many `Lift` instances exist? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10795: Upgrade gcc in 7.10
by GHC 26 Aug '15

26 Aug '15

#10795: Upgrade gcc in 7.10 -------------------------------------+------------------------------------- Reporter: joozek78 | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [[http://sourceforge.net/p/mingw-w64/mailman/message/29339395/|this mail thread]]). That's because response files are not used properly by older gcc. '''gcc was upgraded for 7.12 in #10726 so this just needs to be backported''' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10377: Remove double negative of ("Unregisterised", "NO")
by GHC 25 Aug '15

25 Aug '15

#10377: Remove double negative of ("Unregisterised", "NO") -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `settings` file has variable named `Unregisterised` which on most arches is sed to `NO`. I propose that the variable be renamed to `Registered` (dropping the "ised" part as well) so that: {{{ Old New ("Unregisterised", "NO") -> ("Registered", "YES") ("Unregisterised", "YES") -> ("Registered", "NO") }}} Unless someone can come up with a good reason why it should stay as it is, I will submit a patch for this to phabricator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10782: Existential variables not scoped?
by GHC 24 Aug '15

24 Aug '15

#10782: Existential variables not scoped? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I was looking into scoping of type variables, and it looks to me that type-checking the introduction of existentials (that is, checking a GADT pattern-match) doesn't extend the type environment. I doubt there's any way to tickle this bug. But the existential skolems don't seem to be added to the `tcl_tyvars` field of the `TcLclEnv`, which means that inner quantification, should uniques collide(!), might do the wrong thing in `quantifyTyVars`. To be clear, I don't wish the variables actually to scope in Haskell source, just for GHC to remember that the internal variables are in scope, to return from `tcGetGlobalTyVars`. Is my analysis wrong somewhere? Do we just assume that uniques being unique will take care of this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1830: Automatic derivation of Lift
by GHC 24 Aug '15

24 Aug '15

#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | 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 Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:12 mpickering]: > Is it possible to derive these instances using GHC.Generics? I believe so, although with `GHC.Generics` you cannot have special cases for unlifted types like `Int#` (currently, the Phab differential uses the [http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH-Syntax.html#t:Lit Lit] type from `template-haskell` to deal with them). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1830: Automatic derivation of Lift
by GHC 24 Aug '15

24 Aug '15

#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | 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 Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by mpickering): Is it possible to derive these instances using GHC.Generics? Then the DeriveAnyClass extension could be used for the same syntactic effect without modifying the compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8
by GHC 24 Aug '15

24 Aug '15

#8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Changing type signature of comparison primops from `Bool` to `Int#` in GHC 7.8 (see #6135) caused a problem: type signatures of functions might be different for the bootstrapping compiler (if it is older than 7.8) than they are for the stage1 compiler. In order to solve this problem I introduced a compatibility module [[GhcFile(compiler/utils/ExtsCompat46)]] that provides different definition of primops for older versions of GHC (`__GLASGOW_HASKELL__ <= 706`) and different for newer versions (`__GLASGOW_HASKELL__ > 706`). However, once we set minimal version of GHC required for bootstrapping to be 7.8, we can (and should!) remove that compatibility module and go back to using GHC.Exts. This ticket is a reminder that we should do this after we release GHC 7.10 or 7.12. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4