June 2015 - ghc-tickets

[GHC] #10533: Typechecker behaves differently on Phab and on Mac
by GHC 18 Jun '15

18 Jun '15

#10533: Typechecker behaves differently on Phab and on Mac -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On my Mac, commit 61b96a86c5342fb1c850361177d60fe855d948f6 causes test `typecheck/should_compile/FD3` to fail. But Phab succeeded in validating this commit, as seen [https://phabricator.haskell.org/B4297 here]. (I don't believe that commit has anything to do with the failure -- it's just the snapshot I looked at.) This leads to two questions: 1. Why does this test fail on a Mac? 2. Why does the typechecker behave differently, at all, on two different platforms? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #4945: Another SpecConstr infelicity
by GHC 18 Jun '15

18 Jun '15

#4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T4945 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I'm closing this again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4945#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4945: Another SpecConstr infelicity
by GHC 18 Jun '15

18 Jun '15

#4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | simplCore/should_compile/T4945 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"5d98b6828f65ce6eea45e93880928b7031955d38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5d98b6828f65ce6eea45e93880928b7031955d38" Trac #4945 is working again This test greps in the ouput of -ddump-simpl, so it's fragile. It stopped working for a while, but now works again. I don't know why, but I don't have time to investigate, so I'll just mark it as ok. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4945#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled
by GHC 18 Jun '15

18 Jun '15

#10504: GHC panics with dsImpSpecs on SPECIALISE pragma with -fhpc enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Minimal example code: https://github.com/nh2/ghc-omit-interface-pragmas- dsImpSpecs-bug/ I'm encountering a problem that prevents me from using Haskell program coverage on a code base, getting a GHC panic referring to `dsImpSpecs`. This looks pretty much like this old bug: https://ghc.haskell.org/trac/ghc/ticket/4870 I checked that it happens on GHC 7.8.4 and GHC 7.10.1. ---- The problem happens when I run `cabal build --ghc-options "-fhpc"`, giving me {{{ Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0... Building ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0... Preprocessing library ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0... [1 of 2] Compiling A ( src/A.hs, dist/build/A.o ) [2 of 2] Compiling B ( src/B.hs, dist/build/B.o ) src/B.hs:5:1: Warning: SPECIALISE pragma for non-overloaded function ‘myfun’ ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): dsImpSpecs ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 $ cabal --version cabal-install version 1.18.0.8 using version 1.18.1.5 of the Cabal library }}} This doesn't happen when I compile directly with `ghc --make`: {{{ $ cd src && ghc --make -fhpc -fomit-interface-pragmas B.hs -Wall [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) }}} So running cabal with `-v`, I see that the problem happens in: {{{ /home/niklas/opt/ghc-7.8/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package-name ghc-omit-interface- pragmas-dsImpSpecs-bug-0.1.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -XHaskell98 B A -Wall -fhpc [1 of 2] Compiling A ( src/A.hs, dist/build/A.o ) [2 of 2] Compiling B ( src/B.hs, dist/build/B.o ) src/B.hs:5:1: Warning: SPECIALISE pragma for non-overloaded function ‘myfun’ ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): dsImpSpecs ghc-omit-interface-pragmas-dsImpSpecs-bug-0.1.0.0:A.myfun{v rpu} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So there it be some flag that cabal passes to GHC that makes this GHC crash appear. Nevertheless, it's a panic, so I guess it's a bug in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10131: improve error message for build on noexec-mounted device
by GHC 17 Jun '15

17 Jun '15

#10131: improve error message for build on noexec-mounted device -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- i was building (in a sandbox) on a ramdisk that was accidentally mounted with the noexec flag. for example during the install of `vector`, you get an error like Loading package primitive-0.5.4.0 ... <command line>: can't load .so/.DLL for: somepath/.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so (somepath /.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so: failed to map segment from shared object) relevant output of `mount`: none on somepath type tmpfs (rw,nosuid,nodev,noexec,relatime,gid=103,user=lspitzner) this is by far no minimal test-case, but i hope my description of the problem is sufficient. if not, i can provide verbose output for my or other test-cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): Ok, I am just pointing out that the implementation is weird from my point of view. I don't want to make a big fuss about this, but I feel that it's something that should be considered. I suppose in a few years someone may raise the issue again :) Regarding blame: The point is that if you get a value of an empty type in your context, it is the caller which is to blame. The proper way to report this blame at runtime is force the caller to produce the value, by forcing it. If you raise an exception yourself you get the blame instead, and so it is harder to track which code is really wrong. I think that a good entry point to the concept of blame is "Well-typed programs can't be blamed" http://homepages.inf.ed.ac.uk/wadler/topics/blame.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): @jpbernardy, I think there are couple of different issues involved here; 1. This patch doesn't change anything about GHC-derived method implementations. Standalone deriving was already generating this code, but the documentation isn't talking about this explicitly. (It's saying "GHC does not restrict the form of the data type. Instead, GHC simply generates the appropriate boilerplate code for the specified class, and typechecks it" https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.ht…) Generated methods are always well-typed, and it's using `error` this way. We merely made non-standalone deriving to work similarly on empty data types, which shouldn't be a problem for anyone, IMO. So the thing you're complaining about was already there for a long time now. We just change some things for consistency and document it. (Also, this patch improves the error message which is always good) 2. I feel like if we force arguments, someone will come here and complain about it too. For example, currently this code works fine: `let g = g in g == g` where type of `g` is empty. If we force it in a non-threaded runtime it'd just loop. (I don't fully understand types-as-contract argument, can you point me to some resources about that?) I also don't care myself, but I feel like we should make this working same as standalone deriving, and document how it is working. Changing standalone deriving for empty types can potentially break existing code, so this may be our only option forward. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by simonpj): What if the method does not have an `a` argument? `Read` is one example, but there are probably others. `Ix` perhaps. Still, I really don't care myself. What I want is for someone to be able to look in the user manual and correctly predict what derived instance you'll get for an empty data type. If you and osa1 agree, I bet everyone else will too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): simonpj: I'm not sure we're talking about the same thing. The whole point of my request was that, for any class C a where all methods have an `a` argument, it is trivial to implement a meaningful instance C Foo for any empty type Foo. In fact, I am guessing that the instance generator for Eq and Ord generate case statements. So, one could just let the normal instance generator run, to get function definitions with empty case statements. I see now that the instance for Read is fine (because failure is the only option), but that is more than I was asking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by simonpj): I'm losing the will to live on this one! > Please, consider forcing the arguments in all these instances, before failing. Not necessarily easy, if the argument is `[a]`, say rather than `a`. This is so much a corner case that what osa1 has implemented seems fine to me. On (3) I suppose that either you can make the `TcDeriv` code check for `isEnumerationOrEmpty` (simplest), or fix the table-generation stuff. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0