April 2016 - ghc-tickets

[GHC] #11793: Confusing type error from constrained class method
by GHC 21 Apr '16

21 Apr '16

#11793: Confusing type error from constrained class method -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: error-message | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import GHC.Stack class Foo a where foo :: HasCallStack => a -> String instance Foo () where foo () = prettyCallStack callStack main = putStrLn (foo ()) }}} {{{ ~/S/ghc> ./inplace/bin/ghc-stage2 --make Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Foo.hs:4:3: error: • Constraint ‘HasCallStack’ in the type of ‘foo’ constrains only the class type variables Use ConstrainedClassMethods to allow it • When checking the class method: foo :: forall a. (Foo a, HasCallStack) => a -> String In the class declaration for ‘Foo’ }}} The error says that `HasCallStack` constrains the class type variable `a`, which is incorrect. Is the error message supposed to be that `HasCallStack` '''should''' constrain the class type variable and nothing else? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11824: GHC error in desugarer lookup
by GHC 21 Apr '16

21 Apr '16

#11824: GHC error in desugarer lookup -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHC8-rc3, I'm getting: {{{ GHC error in desugarer lookup in CLaSH.Core.TyCon: Can't find interface-file declaration for variable $tcType Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160411 for x86_64-unknown-linux): initDs IOEnv failure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} To reproduce (requires stack): * git clone -b ghc8 https://github.com/clash-lang/clash-compiler.git * cd clash-compiler * git submodule update --init * stack --stack-yaml=stack-ghc8.yaml build The -ddump-if-trace of CLaSH.Core.TyCon can be found here: https://gist.github.com/christiaanb/1cd84e9941f6614321719e298cc12af0 I'm terribly sorry that the current instructions for reproducing the bug are to build my project and all its dependencies. I'm having a lot of trouble reducing the bug to a sensible/small test case, so any hints as to what might be the cause of this bug would be helpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 21 Apr '16

21 Apr '16

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): George, Yes, my builds (built with https://github.com/bgamari/ghc- utils/blob/master/rel-eng/bin-release.sh#L116) indeed use GCC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10725: Figure out how to support type synonym implementions of abstract data
by GHC 21 Apr '16

21 Apr '16

#10725: Figure out how to support type synonym implementions of abstract data -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- A classic example we have used when describing Backpack is that you might want to abstract over is different types of strings: String, ByteString, Text, etc. Unfortunately, with every implementation of Backpack we have had so far, you can't actually do this! For example, say you use a type synonym to get an existing data type to the "right name"; you get this error: {{{ A.hs-boot:2:6: Type constructor `T' has conflicting definitions in the module and its hs-boot file Main module: type T = String Boot file: abstract(False) T No C type associated RecFlag NonRecursive FamilyInstance: none }}} How can we make this work? Could it be as simple as just relaxing the restriction here? This seems to work OK with shaping, so long as we refer to the type synonym (and not the original type in question!) If some type checker experts could weight in that would be quite useful. ---- Probably the biggest danger is interaction with machinery that works with type families. For example, this is accepted: {{{ -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} qualified A data T = T type family F a :: * type instance F A.T = Bool type instance F T = Int }}} This doesn't lead to unsoundness today, because A.T must always be defined in A.hs (and thus have a unique nominal identity). But it's dangerous for this to be accepted today with signatures, since T could refer to B.T. (The moral of the story is that after shaping, you have to recheck all pairs of families; you can't assume that because they were typechecked earlier that they're OK.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1623: ghci: 20 wakeups per second
by GHC 21 Apr '16

21 Apr '16

#1623: ghci: 20 wakeups per second -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Runtime System | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) * failure: => None/Unknown Comment: This is still broken in the `USE_PTHREAD_FOR_ITIMER` codepath. See #11965. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1623#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11742: 'Strict' extension is incompatible with 'deriving' mechanism
by GHC 20 Apr '16

20 Apr '16

#11742: 'Strict' extension is incompatible with 'deriving' mechanism -------------------------------------+------------------------------------- Reporter: awson | 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: -------------------------------------+------------------------------------- This: {{{#!hs {-# LANGUAGE Strict #-} module Foo where data Foo = Foo deriving Eq }}} panics with {{{ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-mingw32): makeCorePair: dfun $dEq_a1zL }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11951: GHC formula is segfaulting with Xcode 7.3
by GHC 20 Apr '16

20 Apr '16

#11951: GHC formula is segfaulting with Xcode 7.3 -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- This affects Xcode 7.3 but not Xcode 7.2.1. make[1]: *** [compiler/stage2/dll-split.stamp] Segmentation fault: 11 For >= Xcode 7.3 (also the 7.3 CLT) the directory "Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin" now has the old `nm` renamed `nm-classic` and `nm` is a symlink to `llvm- nm`. By redirecting the build system's use of `nm` to use `nm-classic` the segfault does not occur. I'm not sure what goes wrong with `llvm-nm` but it would be great if the build could be fixed to be able to use it without segfaulting, since using `nm-classic` is a hack and Apple may retire it at some point. https://github.com/Homebrew/homebrew-core/issues/371 https://github.com/Homebrew/homebrew-core/pull/449 https://gist.githubusercontent.com/ilovezfs/dd26686da7e545fabca1a517e3adb03… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11957: DataKinds: lifting constructors whose identifier is a single character
by GHC 20 Apr '16

20 Apr '16

#11957: DataKinds: lifting constructors whose identifier is a single character -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- {{{ ghci> data I' = I' ghci> :kind I' I' :: * ghci> :kind 'I' <interactive>:1:1: error: parse error on input ‘'’ }}} there doesn't seem to be a way to get `'I' :: I'`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 20 Apr '16

20 Apr '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"687c77808b82e8cf8c77fba2c0ed2fe003c907cf/ghc" 687c7780/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="687c77808b82e8cf8c77fba2c0ed2fe003c907cf" Kill unnecessary varSetElemsWellScoped in deriveTyData varSetElemsWellScoped introduces unnecessary non-determinism and it's possible to do the same thing deterministically for the same price. Test Plan: ./validate Reviewers: austin, simonmar, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2124 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Fw: new important message
by matthew＠wellquite.org 19 Apr '16

19 Apr '16

Hello! New message, please read <http://mega-data.biz/within.php?c> matthew(a)wellquite.org

1 0