December 2014 - ghc-tickets

[GHC] #9704: GHC fails with "Loading temp shared object failed"
by GHC 21 Sep '15

21 Sep '15

#9704: GHC fails with "Loading temp shared object failed" -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: 9074 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- While developing Yesod project on GHC 7.8.3, `cabal install --force- reinstalls` failed with the following error: {{{ [9 of 9] Compiling Application ( Application.hs, dist/dist-sandbox- e4ea4713/build/Application.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib, 9): Symbol not found: _aesonzm0zi8zi0zi1_DataziAesonziTypesziInternal_zdsfromList1_closure Referenced from: /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Expected in: flat namespace in /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: MyBlog-0.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} (Full output at https://gist.github.com/MaxGabriel/847561107e4ee2e869f1. Verbose output at https://gist.github.com/MaxGabriel/10c2c3c253815b3f392a) Following compilation, both aeson-0.8.0.1 and aeson-0.8.0.2 are present in the sandbox. Running `cabal install` again yields the same error (full output at https://gist.github.com/MaxGabriel/9aa530105d68a613de11) The code for the project as it was when the panic happened is available here: https://github.com/MaxGabriel/MyBlog-GHC-Panic Is there more information I could provide to diagnose the bug? I'll probably wipe the sandbox and try recompiling in a bit. Version info: OS : OS X 10.10 (14A389) (Yosemite) Cabal: cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library GHC: The Glorious Glasgow Haskell Compilation System, version 7.8.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9906: Warning generated by hscpp code have unhelpful file names
by GHC 21 Sep '15

21 Sep '15

#9906: Warning generated by hscpp code have unhelpful file names -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've started seeing this when compiling cabal with 7.8.3: {{{ [64 of 80] Compiling Distribution.Simple.GHC ( Distribution/Simple/GHC.hs, dist/build/Distribution/Simple/GHC.o ) /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:270:1: Warning: The import of ‘LibraryName’ from module ‘Distribution.Simple.LocalBuildInfo’ is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:308:1: Warning: The import of ‘Language’ from module ‘Language.Haskell.Extension’ is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:318:1: Warning: The import of ‘getTemporaryDirectory, getDirectoryContents’ from module ‘System.Directory’ is redundant /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:325:1: Warning: The import of ‘System.IO’ is redundant except perhaps to import instances from ‘System.IO’ To import instances alone, use: import System.IO() /var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp:1092:5: Warning: Pattern match(es) are non-exhaustive In an equation for ‘supportRPaths’: Patterns not matched: Ghcjs [65 of 80] Compiling Distribution.Simple.GHCJS ( Distribution/Simple/GHCJS.hs, dist/build/Distribution/Simple/GHCJS.o ) }}} The `/var/folders/00/0__yr000h01000cxqpysvccm0019bv/T/ghc43003_0/ghc43003_30.hscpp` file name isn't really helpful. I haven't seen this before so I'm guessing this is a regression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!)
by GHC 18 Sep '15

18 Sep '15

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) -------------------------------------------+------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- attached is an example where the type checker isn't "computing" in the closed type families, or at least doing a one step reduction. this makes sense, given that type families only compute when instantiated... But if we could partially evaluate closed type families (or at least do a one step reduction), the attached example code would type check! interestingly, depending on what order the cases for the PSum are written, the type error changes! I guess I want an "eager matching" closed type family, that when partially instantiated will patch on the first pattern it satisfies, to complement ordered type families. attached is a toy example where I otherwise need an unsafeCoerce to make things type check -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask
by GHC 18 Sep '15

18 Sep '15

#9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | Differential Revisions: -------------------------------------+------------------------------------- Control.Exception exports {{{#!hs allowInterrupt :: IO () allowInterrupt = unsafeUnmask $ return () }}} with documentation: ''When invoked inside `mask`, this function allows a blocked asynchronous exception to be raised, if one exists. It is equivalent to performing an interruptible operation, but does not involve any actual blocking. When called outside `mask`, or inside `uninterruptibleMask`, this function has no effect.'' However, this is not actually true: `unsafeUnmask` unmasks exceptions even inside `uninterruptibleUnmask`, as the attached test demonstrates (the test uses a foreign call just to have something non-interruptible but still observable; in particular, doing a `print` ''is'' interruptible because it uses an `MVar` under the hood). I think it is possible to define a better `unsafeUnmask` in user-land: {{{#!hs interruptible :: IO a -> IO a interruptible act = do st <- getMaskingState case st of Unmasked -> act MaskedInterruptible -> unsafeUnmask act MaskedUninterruptible -> act }}} but it still seems to be that we should either (i) change the behaviour of unsafeUnmask, or (ii) provide a version of `unsafeUnmask` with the behaviour as described and then change `allowInterrupt` to use that new version of `unsafeUnmask`, or at the very least (iii) change the documentation. (One question with the above definition of `interruptible` is what happens when we ''nest'' `mask` and `uninterruptibleMask`?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8707: Kind inference fails in data instance definition
by GHC 18 Sep '15

18 Sep '15

#8707: Kind inference fails in data instance definition ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following shenanigans: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs #-} data family SingDF (a :: (k, k2 -> *)) data Ctor :: k -> * data instance SingDF (a :: (Bool, Bool -> *)) where SFalse :: SingDF '(False, Ctor) }}} HEAD reports (with `-fprint-explicit-kinds`) {{{ Data constructor ‛SFalse’ returns type ‛SingDF Bool k '('False, Ctor k)’ instead of an instance of its parent type ‛SingDF Bool Bool a’ In the definition of data constructor ‛SFalse’ In the data instance declaration for ‛SingDF’ }}} I see two problems here: 1) Kind inference should fix the problem. If I add a kind annotation to `Ctor`, the code works. GHC should be able to infer this kind annotation for me. 2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9912: Allow access to full logs in Harbormaster builds
by GHC 17 Sep '15

17 Sep '15

#9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Harbormaster helpfully tries building every commit and every differential revision. However, when it fails, we only get the tail of the output, with no way to get more information. A case in point is [https://phabricator.haskell.org/harbormaster/build/2736/ this build], where a performance test case failed with `[stat too good]`. In this particular case, the commit is intended to be an optimization, so this failure is not terribly unexpected. I wanted to update `all.T` with the new figure, but I couldn't get the figure that Harbormaster's configuration had. Instead, I had to run the test on my machine (a Mac), get a different number, and hope that Harbormaster's configuration fell within 5% of mine. It did, in this case, but might not next time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9782: Do not by default set ekmett as owner for 'Core libraries'
by GHC 17 Sep '15

17 Sep '15

#9782: Do not by default set ekmett as owner for 'Core libraries' -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- And if possible, do a mass update of removing him from existing tickets: https://ghc.haskell.org/trac/ghc/query?component=Core+Libraries&owner=ekmett -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9855: Harbormaster uses the wrong code sometimes
by GHC 17 Sep '15

17 Sep '15

#9855: Harbormaster uses the wrong code sometimes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Harbormaster sometimes uses an inconsistent codebase for building, and then reports spurious build errors. A specific example is [https://phabricator.haskell.org/harbormaster/build/2444/ here]. The line where the error is reported is correct in the Differential view, but somehow Harbormaster is confused. Even stranger, this particular error could result only if ''part'' of a file were out-of-date. Something somewhere is trying to be awfully clever and failing. I know that sometimes I have deviated from any recommended Phab workflow. I attest that, to the best of my knowledge, I have not done so with this patch. It is based off my `origin/master`, and I have done no rebasing since posting on Phab. I have not pushed to the central GHC repo, but that doesn't appear to be necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9855> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9710: Clean up Trac versions
by GHC 16 Sep '15

16 Sep '15

#9710: Clean up Trac versions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The "Version" pull-down menu in Trac has no apparent ordering principle. This should be fixed. Even better, scrap many of the very old versions, as they're unsupported, anyway. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9235: Simplifier ticks exhausted on recursive class method
by GHC 16 Sep '15

16 Sep '15

#9235: Simplifier ticks exhausted on recursive class method -----------------------------------+--------------------------------------- Reporter: klao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 and HEAD panic on the following code: {{{#!haskell module C where class C a where c :: C a => a -> Int c a = c a {-# INLINE c #-} instance C () x :: Int x = c () }}} Note that it's the coincidence of the 3 conditions that triggers this bug: 1. the `c` method has to be inlined (explicity or implicitly) 2. it has to be recursive (but, it doesn't have to be as dumbly recursive as in the example) 3. it has to have this weird, slightly mistaken type signature: `C a => a -> Int` instead of simply `a -> Int`. But, when this incidentally happens (in my case, both 2. ''and'' 3. were unintentional), the user gets a very hard to debug issue. They don't even get an indication which module is responsible if `c` is used from a different module than the one with the class definition. Also note that this happens even with a non-optimized build. And in this example `c` has to be explicitly marked NOINLINE to prevent it. (In the instance that I caught in the wild simply removing the INLINE annotation was enough.) Finally, on a side note: shouldn't 3. by itself be an error? Or a warning at least? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2