May 2015 - ghc-tickets

[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] #9978: DEBUG is always replaced as 1 when CPP pragma is on
by GHC 21 Sep '15

21 Sep '15

#9978: DEBUG is always replaced as 1 when CPP pragma is on -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Trying to compile the following code: {{{ {-# LANGUAGE CPP #-} data Level = DEBUG }}} results in error: {{{ Test.hs:2:14: Illegal literal in type (use DataKinds to enable): 1 }}} which is of course an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global"
by GHC 21 Sep '15

21 Sep '15

#10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ /usr/bin/opt: /tmp/ghc27119_0/ghc27119_272.ll:21159722:1: error: redefinition of global named '@c17Kd9_info' @c17Kd9_info = alias internal i8* bitcast (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c17Kd9_info$def to i8*) ^ <no location info>: ghc: phase `LLVM Optimiser' failed (exitcode = 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10459: -fsimple-tick-factor required
by GHC 21 Sep '15

21 Sep '15

#10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: fsimple- | Operating System: Linux tick-factor | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:Foreign.Storable.$fStorableWord8_$cpokeByteOff{v rsA} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 10400 }}} -fsimple-tick-factor=115 was required See the 'css' branch of https://github.com/mikehat/blaze-markup.git -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #9976: Ignore newlines in code diffs on Phab
by GHC 17 Sep '15

17 Sep '15

#9976: Ignore newlines in code diffs on Phab -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.4 Component: Trac & Git | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Doing code reviews in Phab is great. However, the way that the lint feature works encourages patchers to split lines as they means that more attention is drawn to split lines than perhaps should be. As a concrete example, I'm reading Phab:D538 this morning, and looking at line 402 of !DsArrows. Alan has added a new field to a data structure and needed to insert a `_` to make the code remain well typed... but this forced a line split to avoid a lint error. Now, I have to check if there are any changes in the second half of the line manually, because the character-diff highlighting fails after the line split. Is there a way to improve this behavior? I can think of two approaches: * (Better option) Teach the character-diff highlighting feature to look across linebreaks. * (Worse option) Encourage patchers ''not'' to make new line breaks until their final commit. Suppress lint problems about line breaks by request. This is, of course, minor, but it would certainly be nice! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10035: Harbormaster doesn't post to Differential on success
by GHC 17 Sep '15

17 Sep '15

#10035: Harbormaster doesn't post to Differential on success -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Trac & Git | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I recently posted a small diff to Phab to get a validate running (Phab:D630, if you must know). Harbormaster happily went and validated, but it never told me that it succeeded! Harbormaster's logs show the success, but I was waiting for an email (generated by activity on my diff, not sent directly from Harbormaster). If others think that this might be nice behavior, could we make this the default, the Harbormaster posts to Differential on success or failure? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3