September 2016 - ghc-tickets

[GHC] #10798: Signatures with only types should not be included in unit keys
by GHC 14 Oct '16

14 Oct '16

#10798: Signatures with only types should not be included in unit keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: ⊥ Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose we want to modularize the dependence on `p` in this program: {{{ unit p where module A where data T = T mkT = T unit q where include p module B where import A bar = mkT }}} The obvious signature to write for `A` is: {{{ signature A where data T mkT :: T }}} But this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here. But suppose we change our signature to be: {{{ signature A.Types where data T signature A where import A.Types mkT :: T }}} This is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question. Now there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated. So, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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] #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] #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

[GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings
by GHC 12 Oct '16

12 Oct '16

#12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | 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: -------------------------------------+------------------------------------- The example given in the [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts… #record-pattern-synonyms documentation] gives a warning when compiled with `-Wall`: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# OPTIONS_GHC -Wall #-} module Test where -- Test.hs:13:24: warning: [-Wname-shadowing] -- This binding for ‘x’ shadows the existing binding -- defined at Test.hs:13:15 -- -- Test.hs:13:27: warning: [-Wname-shadowing] -- This binding for ‘y’ shadows the existing binding -- defined at Test.hs:13:18 pattern Point :: Int -> Int -> (Int, Int) pattern Point{x, y} = (x, y) }}} I don't see anything being shadowed here, so I don't think GHC should produce these warnings. Also, the type signature for that example in the documentation is `pattern Point :: (Int, Int)`, which doesn't compile. Should I file a separate bug for that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?)
by GHC 12 Oct '16

12 Oct '16

#12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I didn't find a ticket with this, but with wiki:CustomTypeErrors you can't define a type synonym without it erroring: {{{#!hs -- error: … -- • onetwothree -- • In the type synonym declaration for ‘ERROR’ -- Compilation failed. type ERROR = TypeError (Text "onetwothree") }}} but I often want to abstract over error messages since they are clunky to write at the type level and I often use a similar message in many different type families, especially when they can be determined by a type family. Here's a hypothetical example: {{{#!hs type family Whoami (ty :: Type) :: Symbol where Whoami Int = "a number" Whoami Float = "a number" Whoami [_] = "a list of things" Whoami _ = "something else" }}} I would like to write {{{#!hs type Error ty = TypeError (Text "Expected a <...> but got ":<>: Text (Whoami ty)) }}} ---- Even when ‘inlined’, it displays `Expected a GRUE but got 'Text (Whoami Int)` and not `• Expected a GRUE but got a number.`: {{{#!hs a :: TypeError (Text "Expected a GRUE but got ":<>: Text (Whoami Int)) a = 'a' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12574: Consistent use of sigs vs signatures in warnings
by GHC 11 Oct '16

11 Oct '16

#12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | 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: 11583 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I have a polymorphic local binding without a type signature, `-Weverything` complains: {{{ warning: [-Wmissing-local-sigs] Polymorphic local binding with no type signature: ... }}} However, when I add `-Wno-missing-local-sigs`, I immediately get a deprecation warning ` -Wno-missing-local-sigs is deprecated: it is replaced by -Wmissing- local-signatures` First, the warning with `-Weveryting` should use the non-depricated `signatures` version. Second, the deprecation warning should probably respect my use of `no`: `-Wno-missing-local-sigs` is replaced by `-Wno- missing-local-signatures`, not `-Wmissing-local-signatures`. Obviously, check for similar cases with the other "sigs" options mentioned in #11583. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7