June 2015 - ghc-tickets

Re: [GHC] #393: functions without implementations
by GHC 04 Jun '15

04 Jun '15

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Keywords: newcomer Resolution: None | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rodlogic): Could this cause a bit of confusion when we have Backpack signatures? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10145: :info (->) should list its fixity
by GHC 04 Jun '15

04 Jun '15

#10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The GHC manual states: > * Function arrow is `infixr` with fixity 0. (This might change; I'm not sure what it should be.) Since this isn't the default `infixl 9`, it should be listed when you do `:info (->)`, but currently (at least in 7.8.3) isn't. (Inspired by [http://stackoverflow.com/questions/28916291/associativity- of/28916978#28916978 this Stackoverflow question].) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #393: functions without implementations
by GHC 04 Jun '15

04 Jun '15

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Keywords: newcomer Resolution: None | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: simonpj => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 04 Jun '15

04 Jun '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): @thoughtpolice, so you disabled `shortOutIndirections` *and* CSE? In that case we don't know which is the cause of the difference, right? If you disable CSE by itself, do you still see the difference? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10330: Better Template Haskell error message locations
by GHC 04 Jun '15

04 Jun '15

#10330: Better Template Haskell error message locations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this TH splice {{{ f x = $( [| let g x = (True && 'x', x) in g True |] ) }}} or more generally {{{ f x = $( g [| x |]) }}} Two problems 1. If there is a type error in the spliced-in code, there is no record of the splice in the error message: {{{ TH.hs:5:10: Couldn't match expected type ‘Bool’ with actual type ‘Char’ In the second argument of ‘(&&)’, namely ‘'x'’ In the expression: (True && 'x') In the expression: ((True && 'x'), x_a2qf) }}} I'd like to see {{{ TH.hs:5:10: Couldn't match expected type ‘Bool’ with actual type ‘Char’ In the second argument of ‘(&&)’, namely ‘'x'’ In the expression: (True && 'x') In the splice: $( [| let g x = ... in g True |] ) <------- NB }}} 2. (Less important, and harder to fix.) The error location (column 10) is that of the splice (column 10), not where the reported error really is (column 31). Fixing this would mean round-tripping source location info through TH syntax. Moreover, since the constructed code may be combined from quoted snippets spread over some TH libraries, it's far from clear that the location info would help. Thoughts about fixing (1). This can only arise for untyped splices. (For typed splices we can't get type errors in spliced code.) So the renamer should produce a syntax tree with a variant of `HsPar` saying "here is where I spliced in an expression". Same think for patterns and types; for declarations it would be a bit more fiddly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 04 Jun '15

04 Jun '15

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * cc: simonmar (added) * keywords: => newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5316: Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation command
by GHC 04 Jun '15

04 Jun '15

#5316: Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation command -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: closed Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.0.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 2182 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 2182 Comment: I was reviewing orphan instance tickets, and I think this one was fixed by #2182; Simon's analysis is essentially the same. I can't actually test it on the test-case given because `System.Event.Manager` has changed since then. The one thing that you might find puzzling is the situation with optimization: but actually it is simple to explain: optimization simply means we might tug on more `ModIface`s because we have to process unfoldings, etc. With the fix for #2182, the orphan instances that are pulled in from this process are unaffected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5316#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules
by GHC 03 Jun '15

03 Jun '15

#10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When you have an instance defined in a module that's part of a recursive module loop, when should modules outside the loop see it? Right now, GHC behaves differently depending on whether it's in batch or in single-shot compilation mode. Which one is correct? Dunno! Here's the example (code at the bottom). The gist is that you have two modules A and B that define data types T and U, respectively, which depend on each other, so A and B are recursive modules and we need a boot file -- say, for A. Now suppose we define an instance Eq T in the implementation of A but not in the boot file. B imports the boot file, so it doesn't know about this instance. And then I have some third module, Main, outside the loop, which imports only B. And now the central question: ''Does Main know about the Eq T defined in A?'' We can test how GHC answers this question by defining an (orphan) instance for Eq T in Main. In batch compilation mode, Main is rejected for defining a duplicate instance. In single-shot compilation mode, however, Main is accepted and any equality test in Main uses the locally defined instance; i.e., B doesn't know about A's Eq T and so neither does Main. So which is correct? If you ask me, the latter semantics is correct, but I can see why the former might be argued as well (e.g., according to the fixed-point semantics of import/export described in (1)). In any case, the semantics between the two compilation modes should probably agree, right? {{{#!hs -- A.hs-boot module A where data T -- a mutually recursive data type, along with B.U t :: T -- some value to test for Eq in Main -- B.hs module B(module A, module B) where -- export A.{T,t} since Main doesn't import A import {-# SOURCE #-} A -- mutually recursive data type across modules data U = U | UT T -- A.hs module A where import B -- mutually recursive data type across modules data T = T | TU U -- the true instance instance Eq T where _ == _ = True -- some value to test Eq instance in Main t :: T t = T -- Main.hs module Main where import B -- no import of A -- an orphan instance for Eq T. -- okay in one-shot mode; not okay in batch (--make) mode instance Eq T where _ == _ = False -- in one-shot mode, this prints False main = putStrLn $ show $ t == t }}} Commands and output for batch mode: {{{ $ ghc --make Main [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling A ( A.hs, A.o ) [4 of 4] Compiling Main ( Main.hs, Main.o ) A.hs:8:10: Duplicate instance declarations: instance Eq T -- Defined at A.hs:8:10 instance Eq T -- Defined at Main.hs:7:10 }}} Commands and output for single-shot mode: {{{ $ ghc -c A.hs-boot $ ghc -c B.hs $ ghc -c A.hs $ ghc -c Main.hs $ ghc A.o B.o Main.o -o main $ ./main False }}} Tested on GHC 7.6.3, 7.8.3, and 7.10.1. (1) ''A Formal Specification for the Haskell 98 Module System''. Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. Haskell '02. http://web.cecs.pdx.edu/~mpj/pubs/hsmods.pdf -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 03 Jun '15

03 Jun '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by puffnfresh): Correct, I tried reproducing with HEAD about 3 weeks ago, then again yesterday but it's always consistent. I can still reproduce with 7.10.1, so yeah, it's a little worrying and would be awesome if you could check. My results are published here: https://gist.github.com/puffnfresh/5a841633f0dde81fe7d1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:99> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 03 Jun '15

03 Jun '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Yes. I removed `shortOutIndirections` in `SimplCore`: {{{ diff --git a/compiler/simplCore/SimplCore.hs b/compiler/simplCore/SimplCore.hs index 0a2f8e4..95c5cce 100644 --- a/compiler/simplCore/SimplCore.hs +++ b/compiler/simplCore/SimplCore.hs @@ -667,7 +667,7 @@ simplifyPgmIO pass@(CoreDoSimplify max_iterations mode) -- -- ToDo: alas, this means that indirection-shorting does not happen at all -- if the simplifier does nothing (not common, I know, but unsavoury) - let { binds2 = {-# SCC "ZapInd" #-} shortOutIndirections binds1 } ; + let { binds2 = {-# SCC "ZapInd" #-} if True then binds1 else shortOutIndirections binds1 } ; -- Dump the result of this iteration dump_end_iteration dflags print_unqual iteration_no counts1 binds2 rules1 ; }}} Then I compiled the test in comment:76 with `-fno-cse` and observed the ABI difference went away. So killing CSE may get us a long way for NixOS I admit I tested this on GHC 7.10, and not the HEAD branch. Brian, you couldn't reproduce this on HEAD at all? I can double check this, but that somewhat surprises (and worries!) me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:98> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0