- ghc-tickets - Haskell.org

[GHC] #16084: Improve link times on Windows
by GHC 05 Mar '19

05 Mar '19

#16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the Windows CI builds are typically lasting over 3 hours. The primary cause of this appears to be poor performance in `ld.bfd`, especially when linking testsuite tests. One option to fix this is to try using LLD for linking. Unfortunately the msys2 `gcc` does not support `-fuse-ld=lld`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16396: TH doesn't preserve `forall`
by GHC 05 Mar '19

05 Mar '19

#16396: TH doesn't preserve `forall` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.3 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: -------------------------------------+------------------------------------- I think there are several bugs in the way TH currently deals with type variable quantification. **Background** GHC uses the "forall-or-nothing" rule. This means that, if there is a top- level `forall` in a type signature, that `forall` must bind ''all'' variables being brought into scope in that signature. Examples: {{{#!hs f1 :: a -> a f1 x = x -- OK, no forall f2 :: forall . a -> a f2 x = x -- rejected f3 :: forall a. a -> a f3 x = x -- OK, forall binds all variables f4 :: forall a. a -> a f4 x = helper x where helper :: a -> a -- OK; this uses a already in scope helper _ = x f5 :: forall a. a -> a f5 x = helper x where helper :: forall . a -> a -- OK; a is already in scope helper _ = x f6 :: forall a. a -> a f6 x = helper x where helper :: forall a. a -> a -- this is a new variable `a` helper _ = x -- rejected; the two `a`s are different }}} Upshot: the existence of `forall` matters. **Strangeness 1** {{{#!hs foo1 :: $([t| a -> a |]) foo1 x = x }}} is rejected, because `a` is not in scope. This is incongruent with the treatment of `f1`. One could argue, though, that all type variables used in quotes should be in scope. I would disagree with such an argument (that's not what we do these days in terms), but it's not silly. **Strangeness 2** {{{#!hs foo2 :: $([t| $(varT (mkName "a")) -> $(varT (mkName "a")) |]) foo2 x = x }}} is rejected because `a` is not in scope. This behavior seems just wrong. **Strangeness 3** {{{#!hs foo3 :: $([t| forall . $(varT (mkName "a")) -> $(varT (mkName "a")) |]) foo3 x = x }}} is rejected in the same way as `foo2`. While this ''should'' be rejected (it's `f2`), `-ddump-splices` says that the splice evaluates to `a -> a`; note: no `forall`. So it's rejected under false pretenses. **Strangeness 4** {{{#!hs foo4 :: $([t| forall a . $(varT (mkName "a")) -> $(varT (mkName "a")) |]) foo4 x = x }}} This one is accepted (as it should be), but it produces a warning! {{{ Scratch.hs:51:21: warning: [-Wunused-foralls] Unused quantified type variable ‘a’ In the type ‘forall a. $(varT (mkName "a")) -> $(varT (mkName "a"))’ | 51 | foo :: $([t| forall a . $(varT (mkName "a")) -> $(varT (mkName "a")) |]) | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16359: Test runner warns of missing basline for performance tests with expected changes
by GHC 05 Mar '19

05 Mar '19

#16359: Test runner warns of missing basline for performance tests with expected changes -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.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: -------------------------------------+------------------------------------- When the commit message documents expected performance tests changes, the test runner warns of missing baselines for those tests, but a baseline is not needed, so the warning should ignore such cases. an example: https://gitlab.haskell.org/ghc/ghc/-/jobs/34315 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16251: T5515 broken in devel2 flavour
by GHC 05 Mar '19

05 Mar '19

#16251: T5515 broken in devel2 flavour -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The `T5515` testcase is broken in the `devel2` build flavour: {{{ --- indexed-types/should_fail/T5515.run/T5515.stderr.normalised 2019-01-27 16:01:12.703091135 +0000 +++ indexed-types/should_fail/T5515.run/T5515.comp.stderr.normalised 2019-01-27 16:01:12.703091135 +0000 @@ -1,24 +1,12 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20190127 for x86_64-unknown-linux): + ASSERT failed! + rhs axiom D:R:Argf :: + Arg f = a_asO[sk:1] -- Defined at T5515.hs:15:8 + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/FamInst.hs:<line>:<column> in <package-id>:FamInst -T5515.hs:6:16: - Expecting one more argument to ‘ctx’ - Expected a type, but ‘ctx’ has kind ‘* -> Constraint’ - In the first argument of ‘Arg’, namely ‘ctx’ - In the first argument of ‘ctx’, namely ‘(Arg ctx)’ - In the class declaration for ‘Bome’ - -T5515.hs:14:1: - Type variable ‘a’ is mentioned in the RHS, - but not bound on the LHS of the family instance - In the type instance declaration for ‘Arg’ - In the instance declaration for ‘Some f’ - -T5515.hs:14:10: - Could not deduce (C f a0) - from the context: C f a - bound by an instance declaration: - forall f a. C f a => Some f - at T5515.hs:14:10-24 - The type variable ‘a0’ is ambiguous - In the ambiguity check for an instance declaration - To defer the ambiguity check to use sites, enable AllowAmbiguousTypes - In the instance declaration for ‘Some f’ +Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16208: map/coerce does not fire with all newtypes
by GHC 05 Mar '19

05 Mar '19

#16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider a slightly modified version of T2110, compiled with -O: {{{ #!haskell {-# LANGUAGE GADTs #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE RankNTypes #-} import GHC.Exts import Unsafe.Coerce newtype Age a b where Age :: forall a b. Int -> Age a b foo :: [Int] -> [Int] foo = map id fooAge :: [Int] -> [Age a b] fooAge = map Age fooCoerce :: [Int] -> [Age a b] fooCoerce = map coerce fooUnsafeCoerce :: [Int] -> [Age a b] fooUnsafeCoerce = map unsafeCoerce same :: a -> b -> IO () same x y = case reallyUnsafePtrEquality# (unsafeCoerce x) y of 1# -> putStrLn "yes" _ -> putStrLn "no" main = do let l = [1,2,3] same (foo l) l same (fooAge l) l same (fooCoerce l) l same (fooUnsafeCoerce l) l }}} This code correctly prints "yes" four times, as required by #2110. However, changing the order of type arguments in the definition of Age to: {{{ Age :: forall b a. Int -> Age a b }}} causes the test to fail in one case: `map Age` is no longer simplified to `Age`. The reason is that this change causes the newtype `Age` to have a wrapper, and the map/coerce rule is not detecting it (see Note [Getting the map/coerce RULE to work] and Note [Data con wrappers and GADT syntax]) This ticket is a prerequisite to linear types (since in linear types, all newtypes have wrappers). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal
by GHC 05 Mar '19

05 Mar '19

#14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Template | Version: 8.3 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: -------------------------------------+------------------------------------- Back in September 2015, I [https://mail.haskell.org/pipermail/libraries/2015-September/026117.html proposed] using the `DeriveLift` extension to, well, derive `Lift` instance for data types in the `template-haskell` library. The proposal was well received, but I was unable to implement it at the time due to `DeriveLift`'s newness (having only been introduced in GHC 8.0). Now that GHC 8.0 is the oldest version of GHC that we support bootstrapping with, this is no longer an obstacle. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12596: can't find interface-file declaration
by GHC 05 Mar '19

05 Mar '19

#12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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: -------------------------------------+------------------------------------- full repro at https://github.com/mwotton/liftwoes/issues/1 ``` /home/mark/projects/liftwoes/src/Lib.hs:14:11: error: • Can't find interface-file declaration for variable Data.Text.Internal.pack 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 • In the first argument of ‘(:)’, namely ‘Data.Text.Internal.pack ((:) 'A' [])’ In the first argument of ‘HS.fromList’, namely ``` {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} module Lib where import Data.Data import qualified Data.Set as HS import qualified Data.Text as T import qualified Data.Text.IO as T import Data.Time -- import Instances.TH.Lift import Instances import Language.Haskell.TH.Syntax table = $(do r <- runIO (HS.fromList . T.lines <$> T.readFile "/usr/share/dict/words") [|r|] ) someFunc = do print $ HS.member "foo" table }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16291: Document or enable commented-out sanity check in checkStackChunk
by GHC 05 Mar '19

05 Mar '19

#16291: Document or enable commented-out sanity check in checkStackChunk -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- `checkStackChunk` is currently defined like this: {{{ void checkStackChunk( StgPtr sp, StgPtr stack_end ) { StgPtr p; p = sp; while (p < stack_end) { p += checkStackFrame( p ); } // ASSERT( p == stack_end ); -- HWL } }}} The commented-out assertion makes perfect sense to me, but I can't enable it (causes test failures), and it's not documented why it should not be enabled. I think this catches a bug that needs to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16393: Implement the "Explicit specificity in type variable binders" proposal
by GHC 05 Mar '19

05 Mar '19

#16393: Implement the "Explicit specificity in type variable binders" proposal -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- The [https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0026-explicit-specificity.rst explicit specificity proposal] (aka proposal 26) was accepted 8 months ago. This ticket is to track its implementation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10892: ApplicativeDo should use *> and <*
by GHC 05 Mar '19

05 Mar '19

#10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- From @ekmett: Would it be possible to tweak the generation to use `(<*)` or `(*>)` where appropriate when the result isn't being used? For many Applicatives this can be a massive asymptotic win in terms of sharing and/or computational cost. When desugaring using (<*) you'd just omit any handling of the unused result instead. {{{ (\x y -> ...) <$> foo <* bar <*> baz }}} corresponds to {{{ do x <- foo bar y <- baz return ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30