August 2018 - ghc-tickets

[GHC] #10927: IndexError: pop from empty list
by GHC 09 Aug '18

09 Aug '18

#10927: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: schwab | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- ==== Zum Reproduzieren ==== Während der Ausführung von GET auf `/attachment/ticket/10926/` hat Trac einen internen Fehler gemeldet. ''(Bitte geben Sie hier weitere Details an)'' Anfrageparameter: {{{ {u'action': u'new', 'path': u'10926/', 'realm': u'ticket'} }}} User agent: `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.21 (KHTML, like Gecko) konqueror/4.14.9 Safari/537.21` ==== Systeminformationen ==== ''Systeminformation nicht verfügbar'' ==== Aktive Plugins ==== ''Plugininformation nicht verfügbar'' ==== Python-Zurückverfolgungsinformationen ==== {{{ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/main.py", line 554, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/main.py", line 267, in dispatch iterable=chrome.use_chunked_encoding) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1111, in render_template encoding='utf-8') File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 184, in render return encode(generator, method=method, encoding=encoding, out=out) File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 58, in encode for chunk in iterator: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 350, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 829, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 669, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 774, in __call__ for kind, data, pos in chain(stream, [(None, None, None)]): File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 594, in __call__ for ev in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1309, in _strip_accesskeys for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1298, in _generate for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 706, in _unmark for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 1101, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 118, in __iter__ event = self.stream.next() File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 734, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 702, in _mark for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 362, in _match content = list(content) File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 326, in _match for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 178, in _generate for event in msgbuf.translate(gettext(msgbuf.format())): File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 1051, in translate events = self.events[order].pop(0) IndexError: pop from empty list }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15392: Inconsistency in parsing trailing commas inside import section
by GHC 09 Aug '18

09 Aug '18

#15392: Inconsistency in parsing trailing commas inside import section -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Keywords: | Operating System: Unknown/Multiple imports,trailing,commas | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following Haskell code compiles without problems: {{{#!hs import Data.Bool (Bool,) }}} As I understand, trailing commas are allowed at the end of `import` declaration. But if I have trailing comma inside data type import part, I see parse error: {{{#!hs import Data.Bool (Bool (True,)) }}} I don't see why this code is forbidden. But allowing trailing commas inside parts of data type imports will make support for automatic refactoring tools easier since they don't need to care about this special case for removing trailing comma manually. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13835: ghci with ":set +t" should print type before starting evaluation
by GHC 08 Aug '18

08 Aug '18

#13835: ghci with ":set +t" should print type before starting evaluation -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Not an actual bug, but questionable design perhaps. I think this is backwards, as static analysis comes before evaluation, not after: {{{ Prelude> :set +t Prelude> reverse [True] [True] it :: [Bool] }}} When evaluation raises an exception, no type is printed. {{{ Prelude> :set +t Prelude> True && undefined *** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at <interactive>:8:9 in interactive:Ghci4 }}} For teaching (and for my own sanity) I'd much prefer output in logical succession. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5142: stub header files don't work with the MS C compiler
by GHC 08 Aug '18

08 Aug '18

#5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): No, no one is working on this at the moment as far as I know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5142#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15489: TestCoercion should be a superclass of TestEquality
by GHC 08 Aug '18

08 Aug '18

#15489: TestCoercion should be a superclass of TestEquality -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Given that you can implement {{{#!hs testCoercionFromEquality :: TestEquality f => f a -> f b -> Maybe (Coercion a b) testCoercionFromEquality fa fb = fmap repr $ testEquality fa fb }}} that shows the superclass relationship. Are there enough libraries that implement new instances of `TestEquality` that adding this superclass would break? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12421: TestEquality and TestCoercion documentation is confusing
by GHC 08 Aug '18

08 Aug '18

#12421: TestEquality and TestCoercion documentation is confusing -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the documentation for the `TestEquality` class indicates > This class contains types where you can learn the equality of two types from information contained in terms. Typically, only singleton types should inhabit this class. The `TestCoercion` documentation includes a similar caution about singleton types. But this is far too conservative! Length-indexed vectors can be made valid instances of `TestEquality` and `TestCoercion` in exactly one way: {{{#!hs data Nat = Z | S Nat data Vec a n where Nil :: Vec a 'Z Cons :: a -> Vec a n -> Vec a ('S n) instance TestEquality (Vec a) where testEquality Nil Nil = Just Refl testEquality (Cons _ xs) (Cons _ ys) = fmap (\Refl -> Refl) (testEquality xs ys) testEquality _ _ = Nothing instance TestCoercion (Vec a) where testCoercion xs ys = fmap (\Refl -> Coercion) (testEquality xs ys) }}} Polykinded heterogeneous lists are another nice non-singleton example for which each class has a single "most reasonable" instance: {{{#!hs data HList (f :: k -> *) (xs :: [k]) where HNil :: HList f '[] HCons :: f a -> HList f as -> HList f (a ': as) instance TestEquality f => TestEquality (HList f) where testEquality HNil HNil = Just Refl testEquality (HCons x xs) (HCons y ys) = do Refl <- testEquality x y Refl <- testEquality xs ys Just Refl testEquality _ _ = Nothing instance TestCoercion f => TestCoercion (HList f) where testCoercion HNil HNil = Just Coercion testCoercion (HCons x xs) (HCons y ys) = do Coercion <- testCoercion x y Coercion <- testCoercion xs ys Just Coercion testCoercion _ _ = Nothing }}} I don't know just how far the warning should be weakened; it may make sense to go as far as saying the type should generally be a GADT. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5142: stub header files don't work with the MS C compiler
by GHC 08 Aug '18

08 Aug '18

#5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by thomie): * owner: simonmar => (none) * cc: Phyx- (added) Comment: Azel: you might want to discuss with @Phyx-, but I don't think anyone is working on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5142#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures.
by GHC 08 Aug '18

08 Aug '18

#15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 in context with backpack signatures and their instantiation with concrete implementation. Consider the signature `Abstract` which contains a data `NatType` of kind `Nat`. {{{#!hs {- skipped relevant language extensions -} signature Abstract where import GHC.TypeLits data NatType :: Nat -- comment this out }}} Concrete implementations are unable to instantiate this abstract class during linking {{{#!hs module Concrete where type NatType = 42 }}} This is neither working with explicit .bkp files nor actual cabal package. I have isolated a minimum example into a repository [[https://github.com /piyush-kurur/backpack-nat| a cabal packages]] as well as a [[https://github.com/piyush-kurur/backpack-nat/blob/master/as-bkpfiles /backpack-nat.bkp|single bkp file]]. The urls above also have the associated ghc log messages. The version of ghc I have tested with is 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15468: in ghci -fbreak-on-exception omits exception info
by GHC 08 Aug '18

08 Aug '18

#15468: in ghci -fbreak-on-exception omits exception info -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In ghc 8.4.3 Without -fbreak-on-exception you get a good error message: {{{ ghci -ignore-dot-ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 *** Exception: <interactive>:1:5-13: Non-exhaustive patterns in function + }}} With -fbreak-on-exception there is no info about the exception: {{{ ghci -ignore-dot-ghci -fbreak-on-exception GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 Stopped in <exception thrown>, <unknown> _exception :: e = _ [<unknown>] [<unknown>] Prelude> }}} In addition, contrary to the documentation, it doesn't seem possible to get ghci to print out the value of the exception {{{ <unknown>] [<unknown>] Prelude> :print _exception _exception = (_t1::e) [<unknown>] [<unknown>] Prelude> :info _exception _exception :: e -- Defined in ‘interactive:Ghci3’ [<unknown>] [<unknown>] Prelude> }}} Finally the fact that you get now warning about {{{ let 2 + 2 = 5 }}} or for {{{ 2 = 3 }}} makes me think I should file an ER to add the following to the default warnings for ghci {{{ ghci -ignore-dot-ghci -Wname-shadowing -Wunused-pattern-binds GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 <interactive>:1:7: warning: [-Wname-shadowing] This binding for ‘+’ shadows the existing binding imported from ‘Prelude’ (and originally defined in ‘GHC.Num’) Prelude> 2 = 3 <interactive>:2:1: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: 2 = 3 Prelude> }}} I noticed the second and when googling to see if it had been reported I came across the following which documented the first: https://code.likeagirl.io/2-2-5-and-why-compiler-warnings-are-good- eaadef327146 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10599: Template Haskell doesn't allow `newName "type"`
by GHC 08 Aug '18

08 Aug '18

#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | 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: | -------------------------------------+------------------------------------- Using `type` as a name is, of course, forbidden. OTOH, `type_1` is allowed as a name. However, using GHC 7.10.1 and `ghc --make T.hs` on files: {{{#!hs -- T.hs {-# LANGUAGE TemplateHaskell #-} module T where import Q test -- Q.hs module Q where import Language.Haskell.TH test :: Q [Dec] test = do t <- newName "type" return [FunD t [Clause [] (NormalB $ LitE $ CharL 't') []]] }}} Leads to the following error: {{{ $ ghc --make -ddump-splices T.hs [2 of 2] Compiling T ( T.hs, T.o ) T.hs:6:1: Illegal variable name: ‘type’ When splicing a TH declaration: ident_0 type_1 = type_1 }}} The above example works fine for GHC 7.8.4, so it's a regression. Reference: https://github.com/yesodweb/persistent/issues/412 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20