April 2017 - ghc-tickets

Re: [GHC] #4347: Bug in unification of polymorphic and not-yet-polymorphic type
by GHC 24 Apr '17

24 Apr '17

#4347: Bug in unification of polymorphic and not-yet-polymorphic type -------------------------------------+------------------------------------- Reporter: dolio | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.1 checker) | Keywords: Resolution: wontfix | ImpredicativeTypes 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ImpredicativeTypes -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4347#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4295: Review higher-rank and impredicative types
by GHC 24 Apr '17

24 Apr '17

#4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 6.12.3 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ImpredicativeTypes -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4295#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4281: Make impredicativity work properly
by GHC 24 Apr '17

24 Apr '17

#4281: Make impredicativity work properly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ImpredicativeTypes -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4281#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10619: Order matters when type-checking
by GHC 24 Apr '17

24 Apr '17

#10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | 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: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo True = (\x -> x) :: (forall a. a -> a) -> forall b. b -> b foo False = \y -> y }}} the module compiles. But when I say {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo False = \y -> y foo True = (\x -> x) :: (forall a. a -> a) -> forall b. b -> b }}} it doesn't, failing with {{{ Bug.hs:6:13: Couldn't match type ‘b0 -> b0’ with ‘forall a. a -> a’ Expected type: (forall a. a -> a) -> forall a. a -> a Actual type: (forall a. a -> a) -> b0 -> b0 In the expression: (\ x -> x) :: (forall a. a -> a) -> forall b. b -> b In an equation for ‘foo’: foo True = (\ x -> x) :: (forall a. a -> a) -> forall b. b -> b }}} I believe this behavior stems from the special case in `tcMonoBinds`, for non-recursive functions without a type signature. I believe the bug would be fixed if that function also checks to make sure that there is precisely one clause to the function. Do you agree? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs
by GHC 24 Apr '17

24 Apr '17

#13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I'm not exactly sure if this is the fault of `cpphs` or GHC, but I'll report this issue to GHC Trac for now, since (ostensibly) the only thing that has changed in this equation is the GHC version. Take this file: {{{#!hs {-# LANGUAGE CPP #-} module Bug where foo :: Int #if __GLASGOW_HASKELL__ >= 800 foo = 42 #else foo = "wrong type" #endif }}} Now let's compile it using `cpphs-1.20.4` as a preprocessor. With GHC 8.0, everything works out fine: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs -pgmP cpphs -optP --cpp Warning: Can't find file "/opt/ghc/8.0.2/lib/ghc-8.0.2/include/ghcversion.h" in directories Asked for by: Bug.hs at line 1 col 1 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) }}} But with GHC 8.2.1, things go awry: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs -pgmP cpphs -optP --cpp Warning: Can't find file "/opt/ghc/8.2.1/lib/ghc-8.2.0.20170403/include/ghcversion.h" in directories Asked for by: Bug.hs at line 1 col 1 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:7: error: • Couldn't match expected type ‘Int’ with actual type ‘[Char]’ • In the expression: "wrong type" In an equation for ‘foo’: foo = "wrong type" | 8 | foo = "wrong type" | ^^^^^^^^^^^^ }}} This bug causes several libraries on Hackage which use `cpphs` as a preprocessor to fail when built with GHC 8.2.1, including `Agda`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13605: GHC Bug when updating stack
by GHC 23 Apr '17

23 Apr '17

#13605: GHC Bug when updating stack -------------------------------------+------------------------------------- Reporter: pighcu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/y5/cc8zwjz12w1567wglxgzt05c0000gn/T/ghc39074_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/y5/cc8zwjz12w1567wglxgzt05c0000gn/T/ghc39074_0/libghc_68.dylib: malformed mach-o: load commands size (49368) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13605> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #12913: Port SplitSections to Windows
by GHC 23 Apr '17

23 Apr '17

#12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 -------------------------------------+------------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"f446f6a3cff21bb709ea501c5be87b0282d5da1c/ghc" f446f6a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f446f6a3cff21bb709ea501c5be87b0282d5da1c" First update mingw-w64 packages for 8.4 Summary: Updating to get latest binutils etc. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, snowleopard GHC Trac Issues: #12913 Differential Revision: https://phabricator.haskell.org/D3382 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12913#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1952: Max and Min for Monoid
by GHC 23 Apr '17

23 Apr '17

#1952: Max and Min for Monoid -------------------------------------+------------------------------------- Reporter: conal | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Semigroup.html Semigroup instances] for `Min` and `Max` have been added to base -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1952#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13252: Perf: Make dep_finsts a map from type family Name to Module
by GHC 22 Apr '17

22 Apr '17

#13252: Perf: Make dep_finsts a map from type family Name to Module -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Today, when we do a family consistency check, we always do a pairwise comparison of every module, even though most of the time, the modules don't even define instances of the same family (making the check futile.) A far better strategy is to say, for any family, which modules transitively below us define instances for it, and only check THOSE pairwise. All we have to do is turn dep_finsts from a list of modules into a mapping from type family names to modules; then we can union the maps and do pairwise comparisons as before. Note that we want to RECORD the map from Name to Module, because we expect any family to have instances defined in many modules (Module to Name is better if a single module defines instances for many families, but clearly this is rare.) This is related to #9717, in that the proposed map here is a more coarse version of what was proposed in that ticket. This may strike a happy compromise between keeping interface files small and speeding things up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13599: Something is fishy in Windows hLock implementation
by GHC 22 Apr '17

22 Apr '17

#13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Ever since we merged the package database locking patch (#13194) I have suspected that something isn't quite right in the locking logic on Windows. The first suspicious sign is that we had to limit the locking range (7e273ea28fe3630a8fede75ed28f471b7be21b5f) due to mysterious `ERROR_LOCK_INVALID_RANGE` errors on Harbormaster. While the fix in 7e273ea28fe3630a8fede75ed28f471b7be21b5f seemed to make the issue disappear, we never were able to pin down the issue. However, now I'm seeing the `ERROR_LOCK_INVALID_RANGE` issue once again on my local Windows during `binary-dist-prep`. In particular, it `binary- dist-prep` seems to reliably fail while registering the `compiler` directory. Watching the system calls performed by `ghc-pkg` with `procmon` suggests that the issue is a negative offset being passed to `LockFile`. Moreover, `LockFile` calls from previous `ghc-pkg` invocations show other, apparently random offset values being passed. The offset is passed to `LockFileEx` (the interface used by our `hLock` implementation) via an `OVERLAPPED` structure, which we locally allocate and zero prior to the `LockFileEx` call. I still haven't worked out where these random values are coming from. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5