December 2016 - ghc-tickets

[GHC] #10871: Implement "buildable" interface files which can be directly compiled without source
by GHC 02 Nov '17

02 Nov '17

#10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. And maybe more we haven't thought of yet. The primary function you need to implement is a function from `ModIface`/`ModDetails` to `TcGblEnv`, which can then be fed to the desugarer. I'm looking at what things we need to add to `ModIface` to support this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le
by GHC 02 Nov '17

02 Nov '17

#12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le ---------------------------------+------------------------------------- Reporter: michelmno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+------------------------------------- as detailed in attached log below the initial failure is a reported Segmentation Fault and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8171: Extending ExtendedDefaultRules
by GHC 02 Nov '17

02 Nov '17

#8171: Extending ExtendedDefaultRules ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current `ExtendedDefaultRules` is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today. It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3. {{{ class Defaulting a }}} The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is `Show`, `Eq`, `Ord` or `Defaulting`. I went with `Defaulting` rather than `Default`, because `Default` is a common class in use across the ecosystem from the `data-default` package, and I wanted to avoid gratuitous fallout. This would permit projects like Shae Erisson's `ghclive` from last year that need to use defaulting to not have to shoe-horn unnecessary `Show` constraints onto functions. Even better would be for that class to be polykinded! That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9249: Link to "latest" user's guide
by GHC 01 Nov '17

01 Nov '17

#9249: Link to "latest" user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I search (say, on Google) for a GHC-related bit of documentation, I variously get referred to old manuals. There doesn't seem to a good way for us, the GHC devs, to avoid this. But, perhaps we can include some information in the header of the pages to allow visitors to link to the latest manual, or perhaps to several versions. This header should also include the version number of the GHC that the page is documenting; currently, this info is only in the URL. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks
by GHC 01 Nov '17

01 Nov '17

#12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- GHC 8 has a lot of trouble compiling the following program: {{{#!hs module Serialize where data Result a = Success a | Error String {- 80 guards ghc-7.10.3 -O : 0.3s ghc-8.0.1 -O : 1.8s -} instance Functor Result where {-# INLINE fmap #-} fmap | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f where bool = undefined f = undefined }}} Here are some timing results, depending on the number of `| bool = f` clauses: {{{ * ghc-8.0.1 N clauses : time (s) 10 : 0.61 20 : 0.78 40 : 1.03 80 : 1.64 160 : 2.83 320 : 5.16 640 : 10.37 1280 : 21.16 * ghc-7.10.3 N clauses : time (s) 10 : 0.33 20 : 0.29 40 : 0.34 80 : 0.30 160 : 0.32 320 : 0.35 640 : 0.48 1280 : 0.80 }}} I think this compile time difference is caused by the `CallStack` changes introduced in GHC 8.0. When I use a version of `undefined` that doesn't have a CallStack, there is no difference in compile time when using GHC 7.10 or GHC 8.0. This is my implementation of `undefined` without `CallStack`: {{{ import GHC.Exception (errorCallException) import GHC.Prim (raise#) import Prelude (Char) error :: [Char] -> a error s = raise# (errorCallException s) undefined :: a undefined = error "undefined without callstack" }}} This is the quick and dirty Python script I used to generate those timing results (ghc version is hardcoded): {{{#!py import os import tempfile import time import subprocess def src(n): return ''' module Test where data Result a = Success a | Error String instance Functor Result where {{-# INLINE fmap #-}} fmap {0} where bool = undefined f = undefined '''.format('\n | bool = f' * n) tempfile = tempfile.mktemp('.hs') print('tempfile = {0}'.format(tempfile)) print('N clauses : time (s)') for i in range(8): n = 10 * 2 ** i with open(tempfile, 'w') as f: f.write(src(n)) f.flush() t0 = time.time() subprocess.call(['ghc-8.0.1', '-v0', '-O', tempfile]) t1 = time.time() print(str(n).ljust(10) + ': %.2f' % (t1 - t0)) os.remove(tempfile) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11787: Infer HasCallStack where possible
by GHC 01 Nov '17

01 Nov '17

#11787: Infer HasCallStack where possible -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider {{{ Prelude> :t error error :: GHC.Stack.Types.HasCallStack => [Char] -> a Prelude> :t (\x -> error x) (\x -> error x) :: (?callStack::GHC.Stack.Types.CallStack) => [Char] -> a }}} We would prefer to get the same type for the latter as the former. Moreover, when we execute on #11376 (comment 25), `:t error` will show the more complicated type too. My suggestion: during generalisation, when we see `?callStack::CallStack`, use the built-in type synonym `HasCallStack`. Note that this should only happen if the name used for the implicit parameter is actually `?callstack`. Eric would you like to consider this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11573: CallStacks show up unexpectedly in type of local binding in GHCi
by GHC 01 Nov '17

01 Nov '17

#11573: CallStacks show up unexpectedly in type of local binding in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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 was noticed (in a thread on ghc-devs) that introducing a CallStack- carrying term into the RHS of a let binding in GHCi produces a type which itself carries a callstack. I could be wrong but as far as I know this is a bug: the solver should never introduce a constraint that the user didn't write; it should merely provide an empty callstack in the event that a callstack constraint can't be solved. {{{ Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11298: Implicit call stack empty in instance declarations
by GHC 01 Nov '17

01 Nov '17

#11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following code: {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack class Foo a where foo :: a -> String main = putStrLn $ foo () }}} In GHC 7.11.20151216, the following instances result in no output: {{{#!hs instance Foo () where foo () = prettyCallStack ?loc }}} {{{#!hs fooHelper = prettyCallStack ?loc instance Foo () where foo () = fooHelper }}} Though this one does: {{{#!hs fooHelper () = prettyCallStack ?loc instance Foo () where foo = fooHelper }}} The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12143: ApplicativeDo Fails to Desugar 'return True'
by GHC 31 Oct '17

31 Oct '17

#12143: ApplicativeDo Fails to Desugar 'return True' -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- If I bring in a spurious parameter, ApplicativeDo correctly infers Functor. {{{ Prelude> :t \m -> do { x <- m; return True; } \m -> do { x <- m; return True; } :: Functor f => f t -> f Bool Prelude> :t \m -> do { m; return True; } \m -> do { m; return True; } :: Monad m => m a -> m Bool }}} However, without the spurious parameter, ApplicativeDo assumes monad. {{{ Prelude> :t do { return True; } do { return True; } :: Monad m => m Bool }}} The first block in particular shows two examples that seem inconsistent when placed next to each other. It seems like if 'x' is unused, then 'x <- m' and 'm' should be equivalent. I would expect all of these to desugar to Functor or Applicative. And maybe 'return True' should be Monad, but 'do { return True; }' should be Applicative? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13038: implementation of Modus ponens and Modus tollens
by GHC 29 Oct '17

29 Oct '17

#13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Can we have in Prelude - Booleans, Modus ponens and Modus tollens implemented? Or in another module? reminder:[[BR]] P is a proposition and v(p) is the logic value of P.[[BR]] P is true, v(P) = 1[[BR]] P is false, v(P) = 0[[BR]] P -> Q is always true in propositional logic. Modus ponens:[[BR]] v(P) = 1[[BR]] v(P -> Q) = 1[[BR]] v(Q) = 1[[BR]] v(P) and v(P -> q) are premiss, v(q) is the conclusion.[[BR]] or in a more general form[[BR]] P : X is A[[BR]] P -> Q : A -> B[[BR]] Q : X is B[[BR]] Modus tollens:[[BR]] v(Q) = 0[[BR]] v(P -> Q) = 1[[BR]] v(P) = 0[[BR]] v(Q) and v(P -> Q) are premiss, v(P) is the conclusion.[[BR]] or in a more general form[[BR]] not Q : X is not B[[BR]] P -> Q : A -> B[[BR]] not P : X is not A[[BR]][[BR]] As well as using the numbers 0 and 1 for the respective values false and true, we'll use the letters F for False and T for True.[[BR]] We are always:[[BR]] v(F) = 0[[BR]] v(T) = 1[[BR]] v(P -> Q) = 1[[BR]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11