- ghc-tickets - Haskell.org

[GHC] #14288: ScopedTypeVariables with nexted foralls broken since 8.0.2
by GHC 21 Dec '17

21 Dec '17

#14288: ScopedTypeVariables with nexted foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example fails in 8.2.1 and 8.0.2. Works fine in 7.10.3. If that's intended (that only the first forall has extended scope), I didn't find any mention of that in GHC manual. The two commented out variants work fine in all. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} main :: IO () main = do -- let f :: forall a ref. ref () -> () -- let f :: forall ref. forall a. ref () -> () let f :: forall a. forall ref. ref () -> () f x = let r :: ref () r = x in () return $ f (Just ()) }}} The error (the same in 8.2.1 and 8.0.2) is: {{{#!hs $ ghc --make forall.hs [1 of 1] Compiling Main ( forall.hs, forall.o ) forall.hs:8:21: error: • Couldn't match type ‘ref’ with ‘ref1’ ‘ref’ is a rigid type variable bound by the type signature for: f :: forall a (ref :: * -> *). ref () -> () at forall.hs:6:29 ‘ref1’ is a rigid type variable bound by the type signature for: r :: forall (ref1 :: * -> *). ref1 () at forall.hs:7:22 Expected type: ref1 () Actual type: ref () • In the expression: x In an equation for ‘r’: r = x In the expression: let r :: ref () r = x in () • Relevant bindings include r :: ref1 () (bound at forall.hs:8:17) x :: ref () (bound at forall.hs:7:9) f :: ref () -> () (bound at forall.hs:7:7) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #14590: Sectioned hole oddities
by GHC 21 Dec '17

21 Dec '17

#14590: Sectioned hole oddities -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13050 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #13050 added support for infix holes. However, it seems that the same support was not added for //sectioned// holes, as the following two examples demonstrate: Left-sectioned holes technically work, although they are pretty-printed poorly: {{{#!hs f :: Int -> Int -> Int f x y = (x `_`) y }}} {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:2:12: error: • Found hole: _ :: Int -> Int -> Int • In the expression: _ In the expression: \ x_ -> _ x x_ ) In the expression: ( \ x_ -> _ x x_ )) y • Relevant bindings include y :: Int (bound at Bug.hs:2:5) x :: Int (bound at Bug.hs:2:3) f :: Int -> Int -> Int (bound at Bug.hs:2:1) | 2 | f x y = (x `_`) y | ^^^ }}} Notice the messy `In the expression: \ x_ -> _ x x_ )` part. Right-sectioned holes don't even parse at all: {{{#!hs f :: Int -> Int -> Int f x y = (`_` x) y }}} {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:2:11: error: parse error on input ‘_’ | 2 | f x y = (`_` x) y | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns
by GHC 21 Dec '17

21 Dec '17

#14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns -------------------------------------+------------------------------------- Reporter: kmiyazato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Bang patterns occurring in let-bindings are allowed even if -XBangPatterns extension is not enabled. {{{#!hs -- Compile error in 8.0.2 -- Compiles in 8.2.1 and 8.2.2 main = print (let !x = 1 + 2 in x) }}} {{{#!hs -- Compile error in all of 8.0.2, 8.2.1, and 8.2.2 main = print (let f !x !y = x + y in f 1 2) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14588> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12512: UnboxedTupleRep-related panic involving typeclasses
by GHC 21 Dec '17

21 Dec '17

#12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #11723 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- You can trigger a GHC panic by abusing `UnboxedTupleRep` in just the right way: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UnboxedTuples #-} import GHC.Exts class Wat (a :: TYPE 'UnboxedTupleRep) deriving instance Wat (# a, b #) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): newTyConEtadArity (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is probably a leak that #11723 didn't plug, as it only considered datatypes, not typeclasses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14604: Flag to disable error position description
by GHC 20 Dec '17

20 Dec '17

#14604: Flag to disable error position description -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Now since GHC has carat diagnostics I have heard at least one person ask for a way to disable the old position descriptions (e.g. "in the first argument of ..."). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14537: Do not link to msvcrt.dll
by GHC 19 Dec '17

19 Dec '17

#14537: Do not link to msvcrt.dll ------------------------------------------+---------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Linking) | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------------+---------------------------- msvcrt is a system component and you can't depend on it, it should be either msvcrVERSION.dll if you're using dynamic linkage or nothing if you're using static. https://social.msdn.microsoft.com/Forums/vstudio/en-us/2203f72c- 5f09-4565-97b3-21337672b191/msvcrtdll?forum=vcgeneral More against msvcrt: https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/ GCC solution: http://www.mingw.org/node/25#comment-106 (not sure if it is relevant here) P.S. I am not user of GHC, I am just using one application written in Haskell. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #14596: Remove uses of unsafeGlobalDynFlags for state hack
by GHC 19 Dec '17

19 Dec '17

#14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently there are a variety of uses of the terrible `unsafeGlobalDynFlags` scattered about the compiler to implement `-fno- state-hack`. This global state makes parallel compilation unreliable and complicates API usage. Remove these uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14505: CircleCI only builds pushed heads
by GHC 18 Dec '17

18 Dec '17

#14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- It appears that CircleCI only builds the head commit of pushes. This means that most of our commits are currently going untested. It seems that the ability to build all commits has been an outstanding feature request since February 2017. See, * https://stackoverflow.com/questions/42074618/circleci-build-all- commits-between-last * https://discuss.circleci.com/t/manually-trigger-a-build-all-commits- between-two-revisions/10160/2 It seems like our options are currently to either ensure that people only push on commit at a time or develop some automation to manually trigger commits using the [[https://circleci.com/docs/api/v1-reference/#new- build|API]]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14599: 32-bit Windows test environment
by GHC 18 Dec '17

18 Dec '17

#14599: 32-bit Windows test environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- We will need to add a build environment for 32-bit Windows as we still provide binary distributions for this target. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14597: Consider removing uses of unsafeGlobalDynFlags for -dppr-debug
by GHC 18 Dec '17

18 Dec '17

#14597: Consider removing uses of unsafeGlobalDynFlags for -dppr-debug -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently various functions in `Outputable` use `unsafeGlobalDynFlags` to get the state of `-dppr-debug`. `unsafeGlobalDynFlags` is rather ugly, being a blob of global state spanning both module compilations and GHC API sessions. Consequently, we might consider removing it. On the other hand, `-dppr-debug` is strictly a debug flag and removing `unsafeGlobalDynFlags` would likely require a lot more piping around of `DynFlags`. Consequently I suspect our current compromise of using `unsafeGlobalDynFlags` is the right solution. Nevertheless, I thought I would jot down the task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14597> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0