November 2016 - ghc-tickets

[GHC] #9010: TemplateHaskell leads to an "unknown symbol" error
by GHC 04 Nov '16

04 Nov '16

#9010: TemplateHaskell leads to an "unknown symbol" error ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Code: {{{ {-# LANGUAGE TemplateHaskell #-} module M where import System.Console.Editline import Data.Lens.Template data S = S { _a :: EditLine } makeLens ''S }}} When compiled with `ghc link.hs`, everything is fine; {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package tagged-0.7.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-compat-0.1.1.1 ... linking ... done. Loading package contravariant-0.4.4 ... linking ... done. Loading package distributive-0.4.3.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package comonad-4.0.1 ... linking ... done. Loading package semigroupoids-4.0.1 ... linking ... done. Loading package data-lens-2.10.4 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package data-lens-template-2.1.8 ... linking ... done. }}} However, when compiling with `ghc -package-id editline-0.2.1.1-ef91ae78e7ea1b9142c2fb0b84e85c11 link.hs`, I get {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package editline-0.2.1.1 ... linking ... ghc: /home/feuerbach/work /.cabal-sandbox/lib/i386-linux- ghc-7.6.3/editline-0.2.1.1/HSeditline-0.2.1.1.o: unknown symbol `el_reset' ghc: unable to load package `editline-0.2.1.1' }}} This is a problem because that's how cabal invokes ghc. This looks similar to #4899, except there's nothing "non-standard" here (no profiling or dynamic linking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #12803: Functional dependencies and type families
by GHC 04 Nov '16

04 Nov '16

#12803: Functional dependencies and type families -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider {{{ type family F a :: * class C a b | a -> b instance C p (F q) => C p [q] }}} Is the instance decl OK under the liberal coverage condition? That is, does `(C t [s1], C t [s2])` mean that `(s1 ~ s2)`? NO! The context of the instance declaration means that `p -> F q` but that does not imply `p -> q` unless `F` is injective! So this program is wrongly accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12734: Unexpected context reduction stack overflow
by GHC 04 Nov '16

04 Nov '16

#12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Hello! I don't have a minimal example, but I've got a very clear strange bahavior: We've got a function: {{{ nstar3 :: ( ExprCons t layers m, Bindable t m, Self.MonadSelfBuilder (Binding (Expr2 t layers AnyLayout)) m , ExprInferable t layers m) => m (Binding (PrimExpr2' t layers Star)) nstar3 = Self.put . anyLayout2 =<<& (nstar2 >>= mkBinding) }}} If I use it in a different function and use following explicit type, I get the error: {{{ test_gr3 :: ( ExprCons t layers m, Bindable t m, ExprInferable t layers m , MonadIO m, Show bind, Show (PrimExpr2' t layers Star), layers~'[Data, Type] , Self.MonadSelfBuilder (Binding (Expr2 t layers AnyLayout)) m , bind ~ Binding (PrimExpr2' t layers Star) ) => m bind test_gr3 = do sref <- nstar3 }}} error (while using the function and evaluating monads): {{{ • Reduction stack overflow; size = 201 When simplifying the following type: MonadFix (Self.SelfBuilderT (Binding (Expr2 t0 '[Data, Type] AnyLayout)) m) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the second argument of ‘($)’, namely ‘(test_gr3)’ In the second argument of ‘($)’, namely ‘runInferenceT2 @TermType @Net $ (test_gr3)’ In the second argument of ‘($)’, namely ‘runInferenceT2 @InfLayers @'[Data, Type] $ runInferenceT2 @TermType @Net $ (test_gr3)’ }}} What is "funny" is that if I change the type of `test_gr3` to a very similar one, I just replace the part `=> m bind` with manually expanded one `m (Binding (PrimExpr2' t layers Star))` everything compiles fine. It would be really hard to get minimal example out of it – it uses nested mfixes and will take much time to cut it down. The question is – can we locate the error based on the description? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12787: Weird type constraint with undecidable instances
by GHC 03 Nov '16

03 Nov '16

#12787: Weird type constraint with undecidable instances -------------------------------------+------------------------------------- Reporter: nome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Linux UndecidableInstances | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minimal example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} module Test where class PreOrd a where (<~) :: a -> a -> Bool class PreOrd a => PartialOrd a where tryCompare :: a -> a -> Maybe Ordering instance PartialOrd a => PreOrd a where x <~ y = let cmp = tryCompare x y in cmp == Just LT || cmp == Just EQ class PartialOrd a => TotalOrd a where tcompare :: a -> a -> Ordering instance TotalOrd a => PartialOrd a where tryCompare x y = Just $ tcompare x y instance TotalOrd Int where tcompare x y = compare x y }}} GHC (tested with 7.10.3 and 8.0.1) rejects this with the following error: {{{ test.hs:11:24: error: • Could not deduce (TotalOrd a) arising from a use of ‘tryCompare’ from the context: PartialOrd a bound by the instance declaration at test.hs:10:10-33 Possible fix: add (TotalOrd a) to the context of the instance declaration • In the expression: tryCompare x y In an equation for ‘cmp’: cmp = tryCompare x y In the expression: let cmp = tryCompare x y in cmp == Just LT || cmp == Just EQ }}} After banging my head against this for a while, and having successfully run this in Hugs, I tend to see it as a bug in GHC. Which is to say, I have no idea why tryCompare could possibly require TotalOrd when it's actually defined in its superclass. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12584: Bug (or Unhelpful Error) with TemplateHaskell
by GHC 03 Nov '16

03 Nov '16

#12584: Bug (or Unhelpful Error) with TemplateHaskell -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: -------------------------------------+------------------------------------- To recreate this make a Haskell file say named 'T.hs', with the following code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} (() -> ()) }}} Then try to compile it: {{{ $> ghc-stage2 T.hs [...] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160617 for x86_64-unknown-linux): tcMonoExpr _ [...] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #4162: GHC API messes up signal handlers
by GHC 02 Nov '16

02 Nov '16

#4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2633 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"8a5960ad874d31fcf631b4d427ccd9fae571745c/ghc" 8a5960ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a5960ad874d31fcf631b4d427ccd9fae571745c" Uninstall signal handlers GHC installs signal handlers in runGhc/runGhcT to handle ^C but it never uninstalls them. It can be an issue, especially when using GHC as a library. Test Plan: validate Reviewers: bgamari, erikd, austin, simonmar Reviewed By: bgamari, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2633 GHC Trac Issues: #4162 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4162#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code
by GHC 02 Nov '16

02 Nov '16

#11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Data.Aeson.TH data Record = Record { type_ :: Int } $(deriveJSON defaultOptions{ fieldLabelModifier = \x -> case x of "type_" -> "type" _ -> x } ''Record) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): tcMonoExpr _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12590: GHC panics, -XTypeInType, possibly "cobox" related
by GHC 01 Nov '16

01 Nov '16

#12590: GHC panics, -XTypeInType, possibly "cobox" related -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I get {{{ GHCi, version 8.1.20160902: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Tree ( src/Tree.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160902 for x86_64-apple-darwin): tcTyVarDetails cobox_a15m :: (n_a159[ssk] :: Peano) ~# ('Z :: Peano) }}} on the attached file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10221: LLVM does not work on OSX
by GHC 01 Nov '16

01 Nov '16

#10221: LLVM does not work on OSX -------------------------------------------+---------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- I can't seem to be able to use the LLVM backend on OSX. I get the error: {{{ error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) <no location info>: ghc: phase `Clang (Assembler)' failed (exitcode = 1) }}} This is on GHC 7.10.1 {{{ % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix yongqli@auxiliary ~/secrets/projects/stocvol % opt --version LLVM (http://llvm.org/) LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #7275: Give more detailed information about PINNED data in a heap profile
by GHC 01 Nov '16

01 Nov '16

#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => Other Comment: The current behaviour is not very informative. This would be nice to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7275#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0