October 2016 - ghc-tickets

[GHC] #9717: More lazy orphan module loading
by GHC 14 Oct '16

14 Oct '16

#9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: backpack | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, when we import a module, we eagerly load all of the orphan modules transitively reachable from it (TcRnDriver:tcRnImports). This is a bit of bummer: as module import hierarchies get deeper and deeper, we'll collect more and more orphan instances and load more and more modules eagerly. The idea is to try to arrange for an orphan module not to be loaded, unless we think that it might have a relevant instance. Instead of just recording a list of orphan modules transitively reachable from a module, we will also record a digest of what type classes and types the orphan provides instances for. (This will be similar to the data we record for `ifInstTys` in `IfaceClsInst`.) Now, when we do any operation involving instances, we check and see if there are also orphans which could provide relevant instances (based on the digest) and load those. If an instance could never have been used, we avoid loading its interface file entirely. This doesn't appear to help too much for type families, where we have to load all of the instances anyway in order to check for consistency. A choice to make: Should we record just the class, or also the types involved? It would be best if we could quickly conclude that there are no more instances to load, but this may be difficult if matching against types as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot
by GHC 14 Oct '16

14 Oct '16

#12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- The current state of the `ghc-8.0` branch (a24092ff501028ca1245b508320493f394378495) apparently fails to compile the `singletons` library, yet 8.0.1 and `master` work fine. The compiler appears to loop. See https://github.com/goldfirere/singletons/issues/162#issuecomment-251272894. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 13 Oct '16

13 Oct '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2592 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12689: DataCon wrappers get in the way of rules
by GHC 13 Oct '16

13 Oct '16

#12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- This is a spin-off of https://ghc.haskell.org/trac/ghc/ticket/12618#comment:25: Simon writes there: Actually this is already a problem today. It's just rendered more prominent now that even `(:)` has a wrapper. Consider {{{#!hs data T = MkT {-# UNPACK #-} !Int {-# RULES "fT" f MkT = True "gT" forall x. g (MkT x) = x #-} f :: (Int -> T) -> Bool {-# NOINLINE f #-} f x = True g :: T -> Int {-# NOINLINE g #-} g (MkT x) = x+1 }}} yields {{{ Foo.hs:9:1: warning: [-Winline-rule-shadowing] Rule "fT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' Foo.hs:10:1: warning: [-Winline-rule-shadowing] Rule "gT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' }}} What to do? If we are to match these rules, we really must delay inlining the wrapper for `MkT` (after inlining we get a mess of unboxing etc). So either we must allow you to add a `NOINLINE` pragma to `MkT`; or we must add one automatically (e.g. `NOINLINE [1]`). Delaying all consructor-wrapper inlining to phase 1 is potentially quite drastic, because case-of-known-constructor wouldn't happen until the wrappers are inlined. Maybe that's ok; I'm not sure. Worth trying I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12456: Panics when making a quotation as pattern synonym
by GHC 13 Oct '16

13 Oct '16

#12456: Panics when making a quotation as pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -XPatternSynonyms -XViewPatterns -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> pattern A :: ExpQ; pattern A <- (undefined -> ()) where A = undefined ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): nameModule system $dIP_a4HS Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Language.Haskell.TH> }}} should we be able to use quotations that are pattern synonyms? I have no use for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12456> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10860: The test `setnumcapabilities001` sometimes fails on Phabricator
by GHC 13 Oct '16

13 Oct '16

#10860: The test `setnumcapabilities001` sometimes fails on Phabricator -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 406 }}} https://phabricator.haskell.org/harbormaster/build/5890/ Here it just timed out: https://phabricator.haskell.org/harbormaster/build/5904/?l=0 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12439: DeriveDataTypeable - deriving Data for several type constructor applications
by GHC 13 Oct '16

13 Oct '16

#12439: DeriveDataTypeable - deriving Data for several type constructor applications -------------------------------------+------------------------------------- Reporter: lspitzner | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving #-} import qualified Data.Data data Mu f = Mu (f (Mu f)) deriving instance Data.Data.Data (Mu []) deriving instance Data.Data.Data (Mu IO) }}} produces {{{ Multiple declarations of ‘$t3Ecq4GuAmh1HtkHHwEpyjp’ [..] Multiple declarations of ‘$c3Ecq4GuAmh1HtkHHwEpyjp’ [..] Duplicate type signatures for ‘$t3Ecq4GuAmh1HtkHHwEpyjp’ [..] Duplicate type signatures for ‘$c3Ecq4GuAmh1HtkHHwEpyjp’ [..] }}} As a workaround one can define instances in separate modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12124: Ambiguous type variable: it's a red herring!
by GHC 13 Oct '16

13 Oct '16

#12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | 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: -------------------------------------+------------------------------------- {{{ module Ret where data Whoops = Whoops Int Int foo :: Maybe Int foo = return (case Whoops 1 2 of Whoops a -> a _ -> 0) }}} Note that there is a pattern match error in the case statement, which the compiler correctly reports. However, it first reports the following red herring: {{{ ret.hs:6:7: error: • Ambiguous type variable ‘m0’ arising from a use of ‘return’ prevents the constraint ‘(Monad m0)’ from being solved. Probable fix: use a type annotation to specify what ‘m0’ should be. These potential instances exist: instance Monad IO -- Defined in ‘GHC.Base’ instance Monad Maybe -- Defined in ‘GHC.Base’ instance Monad ((->) r) -- Defined in ‘GHC.Base’ ...plus two others (use -fprint-potential-instances to see them all) • In the expression: return (case Whoops 1 2 of { Whoops a -> a _ -> 0 }) In an equation for ‘foo’: foo = return (case Whoops 1 2 of { Whoops a -> a _ -> 0 }) }}} One would think that the context `foo :: Maybe Int` is sufficient for the compiler to realize that `return (blah)` implies that m0 = Maybe, regardless of the errors involved in the expression `(blah)`. ghc 7.10.3 does not report this red herring. One can get a similar red- herring type error in ghc 7.10.3 by replacing `return (...)` with `return $ ...` in the example above. The red herring also does *not* appear, in ghc 7.10.3 or in ghc 8.0.1, if you name the broken case expression with a let binding. {{{ module Ret where data Whoops = Whoops Int Int foo :: Maybe Int foo = return boo where boo = case Whoops 1 2 of Whoops a -> a _ -> 0 }}} There seems to be something fishy going on here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12693: Relax qualified import syntax
by GHC 13 Oct '16

13 Oct '16

#12693: Relax qualified import syntax -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: import, | Operating System: Unknown/Multiple qualified, syntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10478 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Problem = Case 1. {{{#!hs import Data.HashMap (HashMap) import qualified Data.HashMap as HashMap import Data.Map (Map) import qualified Data.Map as Map import Data.Set (Set) import qualified Data.Set as Set import Data.Text (Text) import qualified Data.Text as Text }}} Module names start in different columns, so the user cannot search it without help of tools, so the code is unreadable. Case 2. {{{#!hs import Data.HashMap (HashMap) import qualified Data.HashMap as HashMap import Data.Map (Map) import qualified Data.Map as Map import Data.Set (Set) import qualified Data.Set as Set import Data.Text (Text) import qualified Data.Text as Text }}} Too many space used, too less space left for imported items list, too hard to maintain without special tools. = Proposal = Allow to write `qualified` keyword after module name: {{{#!hs import Data.HashMap (HashMap) import Data.HashMap qualified as HashMap import Data.Map (Map) import Data.Map qualified as Map import Data.Set (Set) import Data.Set qualified as Set import Data.Text (Text) import Data.Text qualified as Text }}} All the problems solved! This proposal looks a little like ShorterImportSyntax and #10478, but differs from them in such ways: 1. It doesn't actually make imports shorter in visible symbols, only in lines used (in case of very long imported items list), a little. 2. It doesn't introduce new syntax constructions looking like existing but doing other things. 3. It is easy to implement and understand. 4. It looks more natural from the point of view of English language. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12598: configure script: --enable-unregisterised default printed incorrectly
by GHC 12 Oct '16

12 Oct '16

#12598: configure script: --enable-unregisterised default printed incorrectly -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- The help text for the --enable-unregisterised flag to configure renders incorrectly. Instead of printing the actual default, it instead prints the name of the variable holding the default: {{{ --enable-unregisterised Build an unregisterised compiler (enabled by default on platforms without registerised support) [default="$UnregisterisedDefault"] }}} This happens because the help text is generated via a call to the `AC_HELP_STRING` macro: {{{#!m4 AC_HELP_STRING([--enable-unregisterised], [Build an unregisterised compiler (enabled by default on platforms without registerised support) [default="$UnregisterisedDefault"]]) }}} According to the autoconf documentation, "the second argument of `AS_HELP_STRING` is treated as a whitespace separated list of text to be reformatted, and is not subject to macro expansion." (https://www.gnu.org /savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Pretty- Help-Strings.html) - hence why the name of the variable is included in the output instead of its value. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2