May 2017 - ghc-tickets

[GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty`
by GHC 23 May '17

23 May '17

#10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1062, #1176, Differential Revisions: | #7666 -------------------------------------+------------------------------------- GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`. Todo: * refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes. * apply the bug fixes that `pretty` received to GHC's copy, making sure not to pick up any possible new bugs in the process. According to (1): "There is one situation where the laws for pretty are ambiguous and leave room for choice. GHC decided one way and pretty the other." * Find which law that is, and document the differences. This hopefully allows us to close the following tickets for free: #1062, #1176 and #7666, maybe more. Ideally we could remove GHC's copy altogether, but we're not there yet. GHC's copy uses FastString, which is supposedly needed for performance, whereas pretty uses `String`. (1) https://github.com/haskell/pretty/issues/1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules
by GHC 23 May '17

23 May '17

#13727: `-Wmissing-home-modules` doesn't properly recognize filepath-qualified modules -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `-Wmissing-home-modules` feature was implemented in order to be used by Cabal (see also #13129), however it turns out that it currently has a minor bug which makes it much less useful for `cabal` as we can't enable it for executables this way, as Cabal needs to provide the path to the Main module directly. Consider the following two files: - `src-lib/M1.hs` {{{#!hs module M1 where }}} - `src-exe/Main.hs` {{{#!hs import M1 main = return () }}} And now consider the following inconsistent results: Expected good behaviour: {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe Main <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: M1 [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib -isrc-exe M1 Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} Unexpected bad behaviour: {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules src-lib/M1.hs src- exe/Main.hs <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: M1 Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} {{{ ghc-8.2.1 -fforce-recomp -Wmissing-home-modules -isrc-lib M1 src-exe/Main <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: Main [1 of 2] Compiling M1 ( src-lib/M1.hs, src-lib/M1.o ) [2 of 2] Compiling Main ( src-exe/Main.hs, src-exe/Main.o ) Linking src-exe/Main ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9287: changed dependency generation
by GHC 23 May '17

23 May '17

#9287: changed dependency generation ------------------------------------+-------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- "ghc -M" for ghc-7.8.x changed in that an error occurs: {{{ You must specify at least one -dep-suffix }}} By chance (#8746) I found that {{{ ghc -M -dep-suffix "" B.hs }}} works, but only for the new ghc-7.8.x. For module B importing module A the following dependencies are generated: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o : A.hs B.o : B.hs B.o : A.hi # DO NOT DELETE: End of Haskell dependencies }}} The same command used with ghc-7.6.x produces wrong dependencies: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A._o : A.hs B.o B._o : B.hs B.o : A.hi B._o : A._hi # DO NOT DELETE: End of Haskell dependencies }}} Obviously, only for dynamic linking a dep-suffix should be needed. However for ghc-7.6. this must be "dyn" and for ghc-7.8.x this must "dyn_" plus the empty suffix! {{{ ghc-7.6.3 -M -dep-suffix dyn B.hs ghc-7.8.2 -M -dep-suffix dyn_ -dep-suffix "" B.hs }}} Both calls produce: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A.dyn_o : A.hs B.o B.dyn_o : B.hs B.o : A.hi B.dyn_o : A.dyn_hi # DO NOT DELETE: End of Haskell dependencies }}} The changed behavior is not documented in http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/separate- compilation.html#makefile-dependencies The (accidental?) change should also be documented in the release notes! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer
by GHC 23 May '17

23 May '17

#13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeInType #-} data X :: Y where Y :: X }}} The error message is: {{{ Bug.hs:2:11: error: … • GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1cR :-> APromotionErr TyConPE] • In the kind ‘Y’ }}} Originally reported by @mietek in #11821 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13743: Colourise command output
by GHC 23 May '17

23 May '17

#13743: Colourise command output -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Our error messages are now colourful (#10073), can we do the same for the output of commands like `:info`? `:info` has gotten bloated (I also think the context / instance head should be swapped, but that's another story), adding colour would make it easier to read {{{#!html <pre> >>> :i Int data Int = I# E.Int# -- Defined in ‘GHC.Types’ instance Eq Int -- Defined in ‘GHC.Classes’ instance Ord Int -- Defined in ‘GHC.Classes’ instance Show Int -- Defined in ‘GHC.Show’ instance Read Int -- Defined in ‘GHC.Read’ instance Enum Int -- Defined in ‘GHC.Enum’ instance Num Int -- Defined in ‘GHC.Num’ instance Real Int -- Defined in ‘GHC.Real’ instance [safe] NFData Int -- Defined in ‘Control.DeepSeq’ instance Data Int -- Defined in ‘Data.Data’ instance Bounded Int -- Defined in ‘GHC.Enum’ instance O.Outputable Int -- Defined in ‘Outputable’ instance [safe] PrintfArg Int -- Defined in ‘Text.Printf’ instance Integral Int -- Defined in ‘GHC.Real’ </pre> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13733: Simplify constraints on RULES LHS
by GHC 22 May '17

22 May '17

#13733: Simplify constraints on RULES LHS -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- TL;DR: Rewrite rules should be able to match instance methods. I know that the interaction of rewrite rules and classes/instances/methods is unsatisfying, and probably will be for the forseeable future given the current design. But we might still improve little bits. Consider this code: {{{ {-# RULES "[Integer] Eq Refl" forall (xs :: [Integer]). xs == xs = True #-} }}} This is the best I can to express the intention of “dear compile, this is a rule for the equality on lists if the elements are integers”. But what I get is {{{ "[Integer] Eq Refl" [ALWAYS] forall ($dEq_a1Jv :: Eq [Integer]) (xs_a1Hd :: [Integer]). == @ [Integer] $dEq_a1Jv xs_a1Hd xs_a1Hd = GHC.Types.True }}} which is a rule about the method `==` applied to ''any'' evidence of equality about lists. This works in the most obvious cases, such as {{{ alwaysTrue :: [Integer]-> Bool alwaysTrue xs = xs == xs }}} but it does not fire with {{{ delayedId :: a -> a delayedId x = x {-# INLINE [0] delayedId #-} alwaysTrue :: [Integer]-> Bool alwaysTrue xs = xs == delayedId xs {-# NOINLINE alwaysTrue #-} }}} The reason is that directly after the simplifier, in the former case, the Core looks like this {{{ $dEq_a1HH :: Eq [Integer] [LclId, Str=DmdType] $dEq_a1HH = GHC.Classes.$fEq[] @ Integer integer- gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger alwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool [LclIdX, Str=DmdType] alwaysTrue = \ (xs_aGT :: [Integer]) -> == @ [Integer] $dEq_a1HH xs_aGT xs_aGT }}} which matches the rule, but in the latter case, by the time the `delayedId` is out of the way, we have {{{ alwaysTrue [InlPrag=NOINLINE] :: [Integer] -> Bool [LclIdX, Arity=1, Str=DmdType <S,U>] alwaysTrue = \ (xs_aGT :: [Integer]) -> GHC.Classes.$fEq[]_$c== @ Integer integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger xs_aGT xs_aGT }}} One possible way forward would be to simplify the wanted constraints on the LHS of the rule using the instances in scope: {{{ "[Integer] Eq Refl" [ALWAYS] forall (xs_a1Hd :: [Integer]). GHC.Classes.$fEq[]_$c== @ Integer integer-gmp-1.0.0.1:GHC.Integer.Type.$fEqInteger xs_a1Hd xs_a1Hd = True }}} This might be tricky, of course, as this requires not only help from the type checker, but also some careful tuned simplification of the LHS afterwards (e.g. unfold dictionary accessors)). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13092: family instance consistency checks are too pessimistic
by GHC 22 May '17

22 May '17

#13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- FamInst has this logic for checking type family instance consistency among imports: {{{ Note [Checking family instance consistency] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For any two family instance modules that we import directly or indirectly, we check whether the instances in the two modules are consistent, *unless* we can be certain that the instances of the two modules have already been checked for consistency during the compilation of modules that we import. [...] How do we know which pairs of modules have already been checked? Any pair of modules where both modules occur in the `HscTypes.dep_finsts' set (of the `HscTypes.Dependencies') of one of our directly imported modules must have already been checked. Everything else, we check now. (So that we can be certain that the modules in our `HscTypes.dep_finsts' are consistent.) }}} However, suppose one of the modules `A` we import directly is itself a type family instance module. Then it too has been checked for consistency with its dependencies `B`, `C`, etc., so we should skip checking the pairs `A` & `B`, `A` & `C`, etc. The current behavior means that whenever we directly import a type family instance module, we still have to load the interface files for all its type family module dependencies, which largely defeats the purpose of the optimization in this case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13629: sqrt should use machine instruction on x86_64
by GHC 22 May '17

22 May '17

#13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D3265 | Wiki Page: -------------------------------------+------------------------------------- The NCG currently implements the square root MachOp with an out-of-line call. This resulted in a large performance regression in `n-body` (see #13570). Fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13570: CoreFVs patch makes n-body slower
by GHC 22 May '17

22 May '17

#13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- This commit {{{ commit 751996e90a964026a3f86853338f10c82db6b610 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Apr 7 17:10:07 2017 +0100 Kill off complications in CoreFVs }}} makes `n-body` in nofib go 25% slower. See [https://perf.haskell.org/ghc/#revision/751996e90a964026a3f86853338f10c82db6… perf results page]. Investigate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13570> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #4: -fext-core -fno-core behaves funny
by GHC 22 May '17

22 May '17

#4: -fext-core -fno-core behaves funny --------------------------------+-------------------- Reporter: josefs | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: None Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0