January 2017 - ghc-tickets

[GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals
by GHC 22 Jan '17

22 Jan '17

#13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- Currently, TH expressions and patterns store Float/Double values as rationals: http://hackage.haskell.org/package/template- haskell-2.11.1.0/docs/Language-Haskell-TH-Syntax.html#t:Lit Unfortunately, this isn't sufficient, as there is no way to properly support usual floating point values such as NaN, Infinity, and Negative- Zero. This is true for both expressions and patterns. It would be nice if Double/Float literals were stored as double-floats themselves, instead of rationals. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 22 Jan '17

22 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): Another suggestion is to add to the repo a big patch file that we apply to the untarred GMP 5.0.4 source to turn it into the GMP 6.1.2 source. (We apply some other patches after unpacking already.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 22 Jan '17

22 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): A suggestion is for now to just turn `libraries/integer-gmp/gmp/tarball` into a submodule `gmp-tarballs.git`, so we can add the new GMP tarball to it, without permanently increasing the size of `ghc.git`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 22 Jan '17

22 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): hvr, I'm going to add the new tarball to the repo unless this gets resolved in another way within the next week (since the branch is a little more than a week away). Okay? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 22 Jan '17

22 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * owner: => hvr -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 22 Jan '17

22 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * priority: high => highest * owner: rwbarton => Comment: Never mind, I guess automatically fetching things from the network is unacceptable. hvr: what am I supposed to do here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 22 Jan '17

22 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: I seem to recall hvr didn't want another gmp binary tarball added to the ghc repo. I'll try to implement fetching of the gmp release tarballs as part of the build process. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12785: GHC panic, TypeFamily in equality constraint
by GHC 22 Jan '17

22 Jan '17

#12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Compiling the attached module I get {{{ $ ghc --interactive Tree.hs GHCi, version 8.1.20161030: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Tree ( Tree.hs, interpreted ) Tree.hs:28:63: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161030 for x86_64-apple-darwin): tcTyVarDetails cobox0_a1eK :: (m_a1ej[sk:2] :: Peano) ~# ('S n_a1eJ[ssk:3] :: Peano) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:457:22 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When switching the call to `SBranchX` in line 29 to a call to `SBranch` the program compiles. So I suspect that the problem is rooted in the extra constraint attached to constructor `SBranchX`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13159: Allow visible type application with pattern synonyms in patterns
by GHC 22 Jan '17

22 Jan '17

#13159: Allow visible type application with pattern synonyms in patterns -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature | Status: new request | 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: #13158 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Somewhat related to #13158, it would be nice if pattern synonyms allowed visible type application with the `TypeApplications` extension enabled. This would obviously be tricky due to the existing meaning of `@` in patterns, though I think it would technically be unambiguous here. Still, I’d understand if you didn’t want to complicate the parser that much further. The motivator, though, is that it would be nice to be able to write pattern synonyms with ambiguous types an explicitly instantiate them, for the same reason type applications are useful for terms. As mentioned in #13158, this would permit writing a pattern synonym to emulate case analysis on types: {{{#!hs {-# LANGUAGE GADTs, PatternSynonyms, ScopedTypeVariables, TypeApplications, TypeOperators, ViewPatterns #-} import Data.Typeable viewEqT :: forall b a. (Typeable a, Typeable b) => a -> Maybe ((a :~: b), b) viewEqT x = case eqT @a @b of Just Refl -> Just (Refl, x) Nothing -> Nothing pattern EqT :: forall b a. (Typeable a, Typeable b) => (a ~ b) => b -> a pattern EqT x <- (viewEqT @b -> Just (Refl, x)) }}} If visible type applications were permitted in patterns, then such case analysis could be written like this: {{{#!hs evilId :: Typeable a => a -> a evilId (EqT @Int n) = n + 1 evilId (EqT @String str) = reverse str evilId x = x }}} …which I think looks relatively pleasant! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9223: Type equality makes type variable untouchable
by GHC 21 Jan '17

21 Jan '17

#9223: Type equality makes type variable untouchable -------------------------------------------+------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This doesn't look right: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} type family TF (m :: * -> *) run1 :: (forall m . Monad m => m a) -> a run1 = undefined run2 :: (forall m . (Monad m, TF m ~ ()) => m a) -> a run2 = undefined -- this works x1 = run1 (return ()) -- this fails x2 = run2 (return ()) {- Couldn't match expected type ‘a’ with actual type ‘()’ ‘a’ is untouchable inside the constraints (Monad m, TF m ~ ()) bound by a type expected by the context: (Monad m, TF m ~ ()) => m a at untouchable.hs:15:6-21 ‘a’ is a rigid type variable bound by the inferred type of x2 :: a at untouchable.hs:15:1 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ‘return’, namely ‘()’ In the first argument of ‘run2’, namely ‘(return ())’ -} }}} I would expect x2 to type check just like x1 does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13