February 2016 - ghc-tickets

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 15 Feb '16

15 Feb '16

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by gkaracha): * cc: gkaracha (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10478: Shorter import syntax
by GHC 15 Feb '16

15 Feb '16

#10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It would be helpful to support a short syntax for importing unqualified identifiers while establishing a short qualified name. An example of the proposed syntax is, {{{#!hs import Data.Map (Map) as M }}} The desired semantics are that `Map` be imported unqualified, and `M` be defined as an alias for `Data.Map`. This replaces the existing convention of writing, {{{#!hs import Data.Map (Map) import qualified Data.Map as M }}} The proposed syntax is currently an error, I think, so adding support for it should not break anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10478> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

Re: [GHC] #2159: Use a more efficient representation than [DynFlag]
by GHC 15 Feb '16

15 Feb '16

#2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Great! Bring it on! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2159#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11206: ARM is generally a disaster
by GHC 15 Feb '16

15 Feb '16

#11206: ARM is generally a disaster --------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- I'll be recording the state of the testsuite on ARM here as I try to trace down the villains that plague this poor architecture. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #11566: I don't need madvise DONT_NEED
by GHC 15 Feb '16

15 Feb '16

#11566: I don't need madvise DONT_NEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Incorrect | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Many tests fail because of a warning in rts/posix/OSMem.c unable to decommit memory: function not implemented The reason it says "function not implemented" is that the function madvise(..., DONT_NEED) is not implemented. This is on a stock Ubuntu LTS 14.04 machine. The only interesting thing about it is that it's running on a pre-production armv8 processor with a beta 4.2 guest kernel. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11566> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11316: Too many guards warning causes issues
by GHC 14 Feb '16

14 Feb '16

#11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 HEAD warns if you have too many guards, for example: {{{ src/HSE/Bracket.hs:44:5: warning: Too many guards in an equation for ‘needBracket’ Guard checking has been over-simplified (Use: -Wno-too-many-guards to suppress this warning -ffull-guard-reasoning to run the full checker (may increase compilation time and memory consumption)) }}} The code in question is from https://github.com/ndmitchell/hlint/blob/master/src/HSE/Bracket.hs#L44 and reads: {{{#!hs needBracket i parent child | isAtom child = False | InfixApp{} <- parent, App{} <- child = False | isSection parent, App{} <- child = False | Let{} <- parent, App{} <- child = False | ListComp{} <- parent = False | List{} <- parent = False | Tuple{} <- parent = False | If{} <- parent, isAnyApp child = False | App{} <- parent, i == 0, App{} <- child = False | ExpTypeSig{} <- parent, i == 0, isApp child = False | Paren{} <- parent = False | isDotApp parent, isDotApp child, i == 1 = False | RecConstr{} <- parent = False | RecUpdate{} <- parent, i /= 0 = False | Case{} <- parent, i /= 0 || isAnyApp child = False | Lambda{} <- parent, i == length (universeBi parent :: [Pat_]) - 1 = False -- watch out for PViewPat | Do{} <- parent = False | otherwise = True }}} For code that runs with the default flags, and likes to have zero warnings (or warnings as errors), and compile with multiple GHC versions, that is problematic. How can I suppress this warning? * Adding {{{-Wno-too-many-guards}}} will only work with GHC 8, so I need to either use CPP to version select my warning suppression, or conditionality outside the compiler select the flags. * Or I can give up on detecting warnings as errors, which is a bit sad, as it's generally a useful criteria. * Or I can modify my code to make it harder to read in order to satisfy a checker whose semantics might change in future. * Or GHC could not warn on too many guards, because it's really a warning that the compiler can't cope, not that too many guards is necessarily bad. I suggest the last option, because warnings should generally be about code issues, not compiler issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11454: Do not suggest deprecated flags
by GHC 14 Feb '16

14 Feb '16

#11454: Do not suggest deprecated flags -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When you misspell the name of a flag, GHC outputs a nice list of similar flags that do exist: {{{ $ ghc-8.0.1 -W-redundant-constraints ghc: unrecognised flag: -W-redundant-constraints did you mean one of: -Wredundant-constraints -Wno-redundant-constraints -fwarn-redundant-constraints }}} But since the `-fwarn` flags are deprecated, they should not be suggested. Neither should any of the other deprecated flags. For a newcomer: the code is `compiler/main/DynFlags.hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8278: Improve error message when the same type is imported from two different library versions
by GHC 14 Feb '16

14 Feb '16

#8278: Improve error message when the same type is imported from two different library versions ------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- When a package indirectly depends on different versions of the same library, ghc reports cryptic error: {{{ Couldn't match expected type `ByteString' with actual type `bytestring-0.9.2.1:Data.ByteString.Internal.ByteString' }}} Error contains fully qualified type with package name and version only when the type is imported from different versions on the library, so looks like ghc knows what is wrong. Is it possible to add something like the next: {{{ Note: ByteString is imported from different package versions: bytestring-0.9.2.1 and bytestring-0.10.0.1 }}} It is inspired by a number of StackOverflow questions (e.g. http://stackoverflow.com/questions/12576817/couldnt-match-expected-type- with-actual-type-error-when-using-codec-bmp/12577025#12577025, http://stackoverflow.com/questions/18767086/bytestring-to-lazy-text-and- vice-versa/18769431?noredirect=1#comment27676563_18769431) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10576: REPL returns list of all imported names when operator completion requested
by GHC 14 Feb '16

14 Feb '16

#10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple completions complete command | Type of failure: Incorrect result operator | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions. For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also. In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge. GHCi behaves similarly with following queries: :complete repl "(>>" :complete repl "Prelude.>>" :complete repl "Prelude.(>>" I only tested this on OS X 10.9, GHC 7.8.4 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #2159: Use a more efficient representation than [DynFlag]
by GHC 14 Feb '16

14 Feb '16

#2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well the bit array was 4x faster than IntSet in my unscientific test. And it would probably be a bit faster still when the option to test is known and can be inlined. But there could be little left to gain after the switch to IntSet. A pretty easy experiment to do, if we had an easy way to benchmark compiler performance... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2159#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0