July 2016 - ghc-tickets

[GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write"
by GHC 01 Sep '16

01 Sep '16

#12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tests `ffi017` and `ffi021` are failing on Windows, for `WAY=ghci`. > During interactive linking, GHCi couldn't find the following symbol: > lseek > During interactive linking, GHCi couldn't find the following symbol: > write These are regressions from 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes
by GHC 01 Sep '16

01 Sep '16

#12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10569 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As a result of #10569, out of scope variables are turned into special type holes so that type information of the variable can be attached to the error message. However, this causes problems when used with `-fdefer-typed-holes` as scope errors have been turned into type errors and are now deferred when using this flag. Richard sums up the situation, "Even if someone is deferring type errors, I imagine most people don't want to defer scope errors". It would be good to add a flag which controls whether out of scope variables are also deferrable when used with existing deferral flags. Goal: Add a flag ` -fdefer-out-of-scope-variables` which controls whether out of scope variables are deferred when using `-fdefer-typed-holes`. It should be turned off by default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4
by GHC 31 Aug '16

31 Aug '16

#12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (I am not sure if this is an issue with the release candidate or with my code. I'm sorry, I've tried hard to investigate that but not come to a firm conclusion. I'm reporting it on the chance that it might be an issue with the release candidate.) The code at https://github.com/bjornbm/dimensional/tree/c5b41bbcecb710d566f8af6e561dcaf… builds and passes tests on 7.8.4 and 7.10.3. The same code fails under 8.0.1-rc4 with the following message: {{{ src/Numeric/Units/Dimensional/Dynamic.hs:79:10: error: • The constraint ‘KnownDimension d’ is no smaller than the instance head (Use UndecidableInstances to permit this) • In the instance declaration for ‘Demotable (Quantity d)’ }}} I'm not sure if the relationship here between `Demotable`, `KnownDimension`, `HasDimension`, and `HasDynamicDimension` in fact requires undecidable instances (in which case 7.8.4 and 7.10.3 are either allowing it in error? or helpfully allowing it even though they aren't obligated to?) or if it does not in fact require undecidable instances (in which case 8.0.1-rc4 is disallowing it in error). Making things even more interesting, a new feature branch of the same project doesn't appear to change any of the things that should be relevant to this error message, but compiles and tests without the error on 8.0.1-rc4 as well as the earlier compiler versions. That one's at https://github.com/dmcclean/dimensional/tree/9f3b0a207258851964defd90ce497e…. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12358: Read1/Read2 don't have methods defined in terms of ReadPrec
by GHC 31 Aug '16

31 Aug '16

#12358: Read1/Read2 don't have methods defined in terms of ReadPrec -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Original Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-June/027102.html > GHC 8.0 added the [http://hackage.haskell.org/package/base-4.9.0.0/docs /Data-Functor-Classes.html Data.Functor.Classes] module to `base`, and with it the `Read1` and `Read2` typeclasses. The current definition of `Read1` is this: > > {{{#!hs > class Read1 f where > liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) > liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a] > }}} > > There's a pretty big problem with this definition: it uses `ReadS` (a synonym for `String -> [(a, String)]`). This sort of parser is very slow (the docs even [http://hackage.haskell.org/package/base-4.9.0.0/docs/Text- ParserCombinators-ReadP.html#t:ReadS admit as such]), and moreover, the actual `Read` typeclass on which Read1 is based tries to avoid using it whenever possible. > > The `Read` typeclass has this definition currently: > > {{{#!hs > class Read a where > readsPrec :: Int -> ReadS a > readList :: ReadS [a] > readPrec :: ReadPrec a > readListPrec :: ReadPrec [a] > }}} > > Where `ReadPrec` is a much more efficient parser datatype. When deriving `Read` instances, GHC defines them in terms of `readPrec`, and gives the other methods default definitions that leverage `readPrec`. > > For the sake of consistency, I propose adding analogous methods to `Read1` and `Read2` that use the `ReadPrec` datatype. For example, here is how I would change `Read1`: > > {{{#!hs > class Read1 f where > liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) > liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a] > liftReadPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a) > liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a] > }}} > > And similarly for `Read2`. Here is a [https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc full gist] with a sketch of what the new `Read1`/`Read2` definitions would look like, including what the default definitions of the other methods would be. Diff coming soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12358> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12177: Relevant bindings includes shadowed bindings
by GHC 30 Aug '16

30 Aug '16

#12177: Relevant bindings includes shadowed bindings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{ ezyang@sabre:~$ ghc-8.0 --interactive GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> \x -> \x -> _ <interactive>:1:13: error: • Found hole: _ :: t2 Where: ‘t2’ is a rigid type variable bound by the inferred type of it :: t -> t1 -> t2 at <interactive>:1:1 • In the expression: _ In the expression: \ x -> _ In the expression: \ x -> \ x -> _ • Relevant bindings include x :: t1 (bound at <interactive>:1:8) x :: t (bound at <interactive>:1:2) it :: t -> t1 -> t2 (bound at <interactive>:1:1) }}} GHC should not report bindings which are shadowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12446: Doesn't suggest TypeApplications when `~` used prefix
by GHC 30 Aug '16

30 Aug '16

#12446: Doesn't suggest TypeApplications when `~` used prefix -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :t undefined @(_ ~ _) <interactive>:1:1: error: Pattern syntax in expression context: undefined@(_ (~(_))) Did you mean to enable TypeApplications? }}} It is suggested with non-`~` type operators {{{ Prelude> :t undefined @((+) _ _) <interactive>:1:1: error: Pattern syntax in expression context: undefined@((+) (_) (_)) Did you mean to enable TypeApplications? }}} but not with {{{ Prelude> :t undefined @((~) _ _) <interactive>:1:15: error: parse error on input ‘)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12446> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12
by GHC 29 Aug '16

29 Aug '16

#12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 -------------------------------------+------------------------------------- Reporter: mistydemeo | 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: -------------------------------------+------------------------------------- GHC failed when trying to build stack from source on MacOS 10.12 using GHC 8.0.1. The relevant part of the error is here: {{{ [ 1 of 87] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, dist/dist- sandbox-68bf8d9c/build/Stack/FileWatch.o ) [ 2 of 87] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/dist-sandbox- 68bf8d9c/build/System/Process/PagerEditor.o ) [ 3 of 87] Compiling System.Process.Log ( src/System/Process/Log.hs, dist /dist-sandbox-68bf8d9c/build/System/Process/Log.o ) [ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-68bf8d9c/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc94633_0/libghc_44.dylib, 5): no suitable image found. Did find: /var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc94633_0/libghc_44.dylib: malformed mach-o: load commands size (40192) > 32768 }}} Full build logs (includes dependency installation via cabal-install): https://gist.github.com/8e005710eab17139c02267bac3029e33 This occurred when installing stack, but reporting here because of the "Please report this as a GHC bug" message in the failed build output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12448: Allow partial application of bidirectional pattern synonyms
by GHC 29 Aug '16

29 Aug '16

#12448: Allow partial application of bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs type Product3 = (,,) }}} Allow {{{#!hs pattern Product3 :: a -> b -> c -> Product3 a b c pattern Product3 = (,,) }}} to mean {{{#!hs pattern Product3 :: a -> b -> c -> Product3 a b c pattern Product3 x y z = (x, y, z) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12448> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12416: Some GCC versions warn about failed inlines
by GHC 29 Aug '16

29 Aug '16

#12416: Some GCC versions warn about failed inlines -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | 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: -------------------------------------+------------------------------------- gcc 4.8.4 on Ubuntu 14.04 warns about failed inlinings. I'm not really sure what to do about this at the moment, so I'm going to leave this here. {{{ In file included from rts/Schedule.h:15:0: error: 0, from rts/Capability.c:23: In function ‘initCapability’: rts/Trace.h:742:20: error: warning: inlining failed in call to ‘traceSparkCounters.part.10’: call is unlikely and code size would grow [-Winline] INLINE_HEADER void traceSparkCounters(Capability *cap STG_UNUSED) ^ cc1: warning: called from here [-Winline] In function ‘yieldCapability’: rts/Trace.h:742:20: error: warning: inlining failed in call to ‘traceSparkCounters.part.10’: call is unlikely and code size would grow [-Winline] INLINE_HEADER void traceSparkCounters(Capability *cap STG_UNUSED) ^ cc1: warning: called from here [-Winline] In function ‘shutdownCapabilities’: rts/Trace.h:742:20: error: warning: inlining failed in call to ‘traceSparkCounters.part.10’: call is unlikely and code size would grow [-Winline] INLINE_HEADER void traceSparkCounters(Capability *cap STG_UNUSED) ^ cc1: warning: called from here [-Winline] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12349: Parallel make should interleave output if it means we can report an error earlier
by GHC 29 Aug '16

29 Aug '16

#12349: Parallel make should interleave output if it means we can report an error earlier -------------------------------------+------------------------------------- Reporter: ezyang | 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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Take the example from #12347 2. Run `ghc --make` and observe what order the modules are reported in (on my box the ordering is `C`, `B`, then `A`) 3. Modify `A` to be a small, quick-to-compile module with a type error. `module A where x = True True` works grand. 4. Run `ghc --make All A B C -j4 +RTS -N4` Expected result: `ghc --make` reports the error in `A` immediately Actual result: `ghc --make` ponders for a while before reporting the error An interesting way to mix up the experiment is to put the type error in `C` rather than `A`. Then indeed the error is reported early, but GHC fails to exit until some undetermined later time (it is certainly not waiting for the other threads to finish compiling, because you don't see object files being produced.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1