- ghc-tickets - Haskell.org

[GHC] #14794: -Weverything should not enable -Wmissing-exported-signatures
by GHC 20 Dec '18

20 Dec '18

#14794: -Weverything should not enable -Wmissing-exported-signatures -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 `-Weverything` compiler flag enables every compiler warning. That includes `-Wmissing-exported-signatures`, which disables `-Wmissing- signatures` (With `-Wmissing-signatures`, every top-level binding without a signature generates a warning, with `-Wmissing-exported-signatures`, only exported bindings generate a warning). While technically "every warning" includes `-Wmissing-exported- signatures`, I don't think this matches how people use `-Weverything`. At least personally I think of it as "`-Wall` isn't enough, give me the strictest possible warning settings", but actually `-Weverything` can have ''fewer'' warnings than `-Wall` because of `-Wmissing-exported- signatures`. Example reproduction case: {{{ -- Main.hs {-# LANGUAGE Safe #-} module Main (main) where import Prelude (IO, putStrLn, show, ($)) import Foo (foo) main :: IO () main = putStrLn $ show foo }}} {{{ -- Foo.hs {-# LANGUAGE Safe #-} module Foo (foo) where import Prelude (Integer) foo :: Integer foo = bar bar = (1 :: Integer) }}} Expected: when compiling with `-Weverything`, I get a superset of `-Wall`'s warnings. Actual: Actual `-Wall`: {{{ maximiliantagher@Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Wall Main.hs Foo.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:10:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: bar :: Integer | 10 | bar = (1 :: Integer) | ^^^ [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} Actual `-Weverything` (note: you should remove run `rm main.o main.hi main Foo.o Foo.hi` in between invocations of the ghc to avoid it using something pre-built): {{{ maximiliantagher@Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Weverything Main.hs Foo.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) <no location info>: warning: [-Wsafe] ‘Foo’ has been inferred as safe! [2 of 2] Compiling Main ( Main.hs, Main.o ) <no location info>: warning: [-Wsafe] ‘Main’ has been inferred as safe! Linking Main ... }}} (I'm not familiar enough with Safe Haskell to get those warnings to go away—I tried the SafeHaskell pragma but that didn't seem to work. In any case, unrelated to this issue) I tested with these versions: * GHC: The Glorious Glasgow Haskell Compilation System, version 8.2.1 * OS Version: Mac OS 10.13.3 (17D47) (High Sierra) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14794> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16072: All dependencies of packages must be explicitly listed when defining flavour packages
by GHC 19 Dec '18

19 Dec '18

#16072: All dependencies of packages must be explicitly listed when defining flavour packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: -------------------------------------+------------------------------------- In the Hadrian user guide, it explains that you can use the `packages` variable in order to describe what is built. However, unless you list all the dependencies of what you want to build also in `packages` then it will fail to build. For example, if I want to just build `ghctags` then I might try to modify `packages` to {{{ ghcTagsPackages stage = case stage of Stage2 -> [ghcTags] _ -> [] }}} but this will fail as I haven't listed any dependencies of `ghcTags` at all. The culprit here is the `contextDependencies` function. {{{ contextDependencies :: Context -> Action [Context] contextDependencies Context {..} = do depPkgs <- go [package] return [ Context depStage pkg way | pkg <- depPkgs, pkg /= package ] where depStage = min stage Stage1 go pkgs = do deps <- concatMapM step pkgs let newPkgs = nubOrd $ sort (deps ++ pkgs) if pkgs == newPkgs then return pkgs else go newPkgs step pkg = do deps <- pkgDependencies pkg active <- sort <$> stagePackages depStage return $ intersectOrd (compare . pkgName) active deps }}} Notice in the definition of `step`, the actual package dependencies are intersected with `stagePackages`. It is also unclear to me why this function is defined recursively as surely when we `need` one dependency, that will in turn `need` its dependencies and so on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8655: Evaluate know-to-terminate-soon thunks
by GHC 19 Dec '18

19 Dec '18

#8655: Evaluate know-to-terminate-soon thunks ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I guess I’ll better put my interior monologue in a ticket than on ghc- dev... In order to implement nested CPR (#1600), I had to enrich the CPR type to keep track of whether something, when entered, will converge for sure. My code does not solve the halting problem, but does only simple stuff, so if something is known to converge, is is very likely to be cheap. Simon suggested to measure the effect of evaluating a let-bound thunk with the known-to-terminate property, as if the body was using it strictly. This tickets tracks this suggestion, and reports progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8655> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #2387: Optimizer misses unboxing opportunity
by GHC 19 Dec '18

19 Dec '18

#2387: Optimizer misses unboxing opportunity -------------------------------------+------------------------------------- Reporter: dolio | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: optimizer | unbox box,CPRAnalysis Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: optimizer unbox box => optimizer unbox box,CPRAnalysis -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2387#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 19 Dec '18

19 Dec '18

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance, CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: boxing, loops, performance => boxing, loops, performance, CPRAnalysis -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8598: IO hack in demand analyzer gets in the way of CPR
by GHC 19 Dec '18

19 Dec '18

#8598: IO hack in demand analyzer gets in the way of CPR ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- After a lot of staring at code and comparing unexpected nofib results I found the following: The IO hack in the demand analyzer (see `dmdAnalAlt` in `StrAnal.lhs` and #1592 for a good discussion) prevents CPR in any function that uses a C call. This is a small example, reduced from the `scaleFloat` method for doubles: {{{ module Float(fun) where import GHC.Float (Double(..)) import GHC.Integer (decodeDoubleInteger, encodeDoubleInteger) fun :: Double -> Double fun x | isFix = x | otherwise = case x of (D# x#) -> case decodeDoubleInteger x# of (# i, j #) -> D# (encodeDoubleInteger i j) where isFix = isDoubleFinite x == 0 foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} Here, `fun` does current not get the CPR property, and the work gets type `GHC.Prim.Double# -> GHC.Types.Double`. Why? Because in core, there will be a {{{ case {__pkg_ccall main isDoubleFinite GHC.Prim.Double# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_dQD ds_dQA GHC.Prim.realWorld# of _ [Occ=Dead, Dmd=<L,A>] { (# ds_dQC [Dmd=<L,A>, OS=OneShot], ds_dQB [Dmd=<S,1*U>] #) -> ... }}} where the case body has `DmdType m {dQz-><L,1*U(U)> dQA-><L,U>}`, but `dmdAnalAlt` detects that this is evaluating a possibly exiting function and throws aways the information using `alt_ty `lubDmdType` topDmdType`. Would it be ok to `lub` only the demand on the free variables, but keep the CPR information? In nofib (if I managed to compare the right results) this does nothing for almost all benchmarks, `-9.2%` of allocations for `mandel` and `+4.9%` for reverse-complement (but these numbers are not obtained very cleanly, and all is happening on top of the better-ho-cardinality branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 19 Dec '18

19 Dec '18

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CPRAnalysis -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:84> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10905: Incorrect number of parameters in "role" errors
by GHC 19 Dec '18

19 Dec '18

#10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: roles | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code produces the error: {{{ import Data.Coerce import Data.Functor.Trans.Tagged toTT :: Tagged t [a] -> TaggedT t [] a toTT = coerce }}} {{{ Couldn't match representation of type ‘[a]’ with that of ‘Data.Functor.Identity.Identity [a]’ arising from trying to show that the representations of ‘Tagged t [a]’ and ‘TaggedT t [] a’ are the same Relevant role signatures: type role [] representational type role Data.Functor.Identity.Identity representational type role TaggedT nominal nominal phantom representational nominal The data constructor ‘Data.Functor.Identity.Identity’ of newtype ‘Data.Functor.Identity.Identity’ is not in scope Relevant bindings include toTT :: Tagged t [a] -> TaggedT t [] a (bound at Main.hs:9:1) In the expression: coerce In an equation for ‘toTT’: toTT = coerce }}} First, kudos for correctly identifying the problem: I failed to import the `Identity` constructor. However, it seems that the report for the roles of the `TaggedT` type has too many parameters. It is defined in tagged-transformer [https://hackage.haskell.org/package/tagged-transformer-0.8/docs/Data- Functor-Trans-Tagged.html] as `newtype TaggedT s m b = TagT { untagT :: m b }`, but is listed with 5 roles. I did try to move the definition of `TaggedT/Tagged` into my module so I didn't have to import the library, but when I did the error didn't show up: TaggedT was listed with the expected roles `phantom representational nominal`. As a user, it wasn't clear to me why there are 5 roles listed for a type with 3 parameters, and I didn't know which roles I should be looking at to help me debug the `coerce` error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16071: GHC is stuck (runs indefinitely) compiling a module
by GHC 19 Dec '18

19 Dec '18

#16071: GHC is stuck (runs indefinitely) compiling a module -------------------------------------+------------------------------------- Reporter: dirtypaw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling [https://github.com/agda/agda/commit/e68360b16af7865519bef77c21c66ff88139ea7e Agda] with ghc-8.6.3 using stack, ghc is stuck at [https://github.com/agda/agda/blob/master/src/full/Agda/Syntax/Internal.hs this module] (runs for 20+ min with no progress). It looks like a regression in ghc-8.6.3 on Windows as Agda is successfully built with ghc-8.6.2 on the same machine, and Agda build with ghc-8.6.3 is generally supported (see [https://github.com/agda/agda/issues/3442 this issue]). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16000: Don't suggest Rank2Types and RankNTypes, only the latter
by GHC 19 Dec '18

19 Dec '18

#16000: Don't suggest Rank2Types and RankNTypes, only the latter -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Parser) | 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 (as of GHC 8.6.2), error messages that suggest RankNTypes also suggest Rank2Types, but Rank2Types are deprecated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4