- ghc-tickets - Haskell.org

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 02 Jun '16

02 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akst): * cc: akst (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4479: Implement TDNR (was: Implement Dot as Postfix Function Apply)
by GHC 02 Jun '16

02 Jun '16

#4479: Implement TDNR -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.5 checker) | 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: | -------------------------------------+------------------------------------- @@ -2,2 +2,1 @@ - [https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordField… - Dot as Postfix Function Apply]. + [https://wiki.haskell.org/TypeDirectedNameResolution TDNR]. New description: A request to implement [https://wiki.haskell.org/TypeDirectedNameResolution TDNR]. -- Comment (by gidyn): Yes, Records/DeclaredOverloadedRecordFields/DotPostfix is orthogonal to type directed name resolution, although spj's original TDNR proposal included both. This ticked was originally about TDNR, then wondered into DotPostfix as an add-on to ORF. As the dot notation has attracted a fair amount of opposition, and ORF only gives TDNR for records, I've brought up a proposal for TDNR over any function but without syntax changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4479: Implement Dot as Postfix Function Apply
by GHC 02 Jun '16

02 Jun '16

#4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.5 checker) | 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 AntC): @gidyn, I don't see what that proposal has to do with dot as postfix function apply (?) This dot as ... idea is not the same as in TDNR -- despite spj's first comment 6 years ago. Dot as ... is purely syntactic sugar for function apply, with type-directed resolution as per standard class/instance semantics. There's already too many proposals for records (and related enablers), without mixing them up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12145: GHC 8.0.1 compilier panic - find_tycon
by GHC 02 Jun '16

02 Jun '16

#12145: GHC 8.0.1 compilier panic - find_tycon -------------------------------------+------------------------------------- Reporter: highfly | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- angie-0.0.0: configure Configuring angie-0.0.0... angie-0.0.0: build Preprocessing library angie-0.0.0... [ 8 of 11] Compiling Handler.Home ( Handler/Home.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package angie-0.0.0 using: /home/haiwei/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:angie exe:angie --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4479: Implement Dot as Postfix Function Apply
by GHC 01 Jun '16

01 Jun '16

#4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.5 checker) | 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 gidyn): There's a proposal for TDNR without syntax changes at SyntaxFreeTypeDirectedNameResolution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7105: Better names for derived SCCs of instances
by GHC 31 May '16

31 May '16

#7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D2282 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7105#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11120: Missing type representations
by GHC 29 May '16

29 May '16

#11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds #-} module Bug where import Data.Typeable foo = typeRep (Proxy :: Proxy '[]) }}} I get {{{ GHC error in desugarer lookup in Bug: Can't find interface-file declaration for variable tc'[] Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151120 for x86_64-apple-darwin): initDs IOEnv failure }}} And I think there may be more trouble. Below are notes I have written to ghc-devs: ------------------------------ I'm a bit confused by the new handling of `Typeable`. 1. You say (in `Note [Grand plan for Typeable]`) that there is trouble making the `TyCon`/`Module` information for the types in `GHC.Types`. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? 2. Even more bizarre would be putting `TyCon`/`Module` info for `GHC.Prim` stuff (I'm thinking about the super-magical `TYPE` from my branch) right in `GHC.Prim`. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that `GHC.Types` itself doesn't try to solve a `Typeable` constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in `Data.Typeable.Internal`. There's also not very many lifted tycons in `GHC.Prim`. I count `TYPE` and `RealWorld`, and that's it. For what it's worth, a weird dependency from `GHC.Prim` to `GHC.Types` actually works in practice. I put `Levity` in `GHC.Types` but `TYPE :: Levity -> TYPE 'Lifted` in `GHC.Prim`. No one complained. 3. Let's assume that we really can't clean up this mess. It still seems that several `TyCon`s are missing from `Data.Typeable.Internal`. Like promoted nil and cons, and `Nat`, and `Symbol`. At the least, we should put a loud comment in the export list of `GHC.Types` saying that everything defined there must be accompanied by a definition in `Data.Typeable.Internal`. 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types`. But this function is used also for things from `GHC.Prim`, like `(->)`. Solving `Typeable (->)` works fine. But I'm sure there's trouble lurking here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 56

Re: [GHC] #487: powerpc/linux segfaulting binaries
by GHC 29 May '16

29 May '16

#487: powerpc/linux segfaulting binaries ----------------------------------+------------------------------- Reporter: dons | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by erikd): * status: new => closed * resolution: None => fixed Comment: Yep, builds fine with 7.10.3. Closing this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/487#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11468: testsuite should ignore config files
by GHC 28 May '16

28 May '16

#11468: testsuite should ignore config files -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Keywords: newcomer | 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 always get a few test failures like the following. {{{ =====> T9360a(normal) 1 of 3 [0, 0, 0] cd ./driver && "/Users/gridaphobe/Source/ghc/build/D1805/inplace/test spaces/ghc-stage2" --interactive -e "" </dev/null > T9360a.run.stdout 2> T9360a.run.stderr Actual stderr output differs from expected: --- /dev/null 2016-01-20 16:43:09.000000000 -0800 +++ ./driver/T9360a.run.stderr.normalised 2016-01-20 16:43:09.000000000 -0800 @@ -0,0 +1,11 @@ +cannot satisfy -package pretty-show + (use -v for more information) + +<no location info>: + Could not find module ‘Text.Show.Pretty’ + It is not a module in the current program, or in any known package. + +<interactive>:7:25: + Variable not in scope: ppShow :: a -> String + +<interactive>:1:1: Not in scope: ‘pprint’ \ No newline at end of file Actual stdout output differs from expected: }}} The failure is due to my `~/.ghci` file, which loads a few packages that ghc-head obviously hasn't built. The testsuite should ignore `~/.ghci` and any other user configuration files that might affect ghc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9224: Add support for binary integer literals
by GHC 28 May '16

28 May '16

#9224: Add support for binary integer literals -------------------------------------------+------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: Keywords: literals | 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: -------------------------------------------+------------------------------- Currently, Haskell98/2010 support base-10, base-8 (via `0[oO]`-prefix) and base-16 (via `0[xX]`-prefix) integer literals. I hereby propose to add conditional support for base-2 integers via a `0[bB]`-prefix, controlled via a new `-XBinaryLiterals` language extension flag/pragma. The change to the lexer is trivial (see attached patch), however I'm stuck on the lexer using a 32-bit feature-mask, of which all 32bits are already taken, and I'd need a 33th bit for the `BinaryLiteralsBit` flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6