June 2018 - ghc-tickets

[GHC] #8263: allow duplicate deriving / standalone deriving
by GHC 04 Jul '18

04 Jul '18

#8263: allow duplicate deriving / standalone deriving ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | 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 would like to avoid conditional compilation. Currently I need to write: {{{ #if MIN_VERSION_Cabal(1,18,0) -- cabal 1.18 has these instances #else deriving instance Typeable Flag #endif }}} Would it be sane to have the deriving instance do nothing if the imported instance that clashes was also derived? reifyInstances together with a fixed #8100 could allow faking this feature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15202: Internal error showing typed hole in GHCi
by GHC 04 Jul '18

04 Jul '18

#15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypedHoles | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Run `ghc --interactive`, and at the prompt type {{{#!hs default () fish :: Eq a => a; fish = undefined foo :: String; foo = show _ }}} The following error appears: {{{ <interactive>:1:1: error: GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r2CZ :-> Identifier[foo::String, TopLevelLet]] }}} I have not yet been able to reproduce this loading a module; it seems to need to be on the command line. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers
by GHC 04 Jul '18

04 Jul '18

#15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let x = () Prelude> let x = () Prelude> :t _ <interactive>:1:1: error: GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} Seems to only happen when there were two identifiers defined with the same name. As verified by mpickering on IRC this isn't reproducible in 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics
by GHC 03 Jul '18

03 Jul '18

#15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: primops | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Add primop support for the following MMX intrinsics: {{{#!c __m64 _mm_cmpeq_pi16 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi32 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi8 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi8 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi16 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi32 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi8 (__m64 a, __m64 b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10391: Ability to get contents of TH reified module
by GHC 02 Jul '18

02 Jul '18

#10391: Ability to get contents of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After using reifyModule, I'd like to be able to inspect the list of exports from that module. At first I thought that this could perhaps be done by changing from {{{#!hs data ModuleInfo = -- | Contains the import list of the module. ModuleInfo [Module] }}} to {{{#!hs data ModuleInfo = -- | Contains the import list and export list of the module. ModuleInfo [Module] [Name] }}} but I now wonder if this is the best plan, because `thisModule >>= reifyModule` might be expected to function as a time machine, allowing us to see declarations that may not have been made yet (in the case where this module's export list is implicit). Can anyone propose a type that would allow us to perform this inspection for modules that have already been baked, but not for "this" module? An intended use case would be in our dimensional types library. We have several modules that define a whole bunch of units. It's useful for the unit name parser to have access to a dictionary with all of those units in it, but maintaining the definition of such a dictionary is redundant. If this feature existed, a module in the parser could import the modules where units are defined, examine the export lists, reify the names in the export lists, determine which represent unit definitions, and emit a declaration of a dictionary that contains them all. (This is in some ways similar to #9699, though perhaps more difficult?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15302: TTG for IPBind wrong extension name
by GHC 02 Jul '18

02 Jul '18

#15302: TTG for IPBind wrong extension name -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: ttg | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The standard[1] for extension naming is to use the `XC` prefix for the internal extension points, rather than for a new constructor. This is violated for `IPBind`, having {{{#!hs data IPBind id = IPBind (XIPBind id) (Either (Located HsIPName) (IdP id)) (LHsExpr id) | XCIPBind (XXIPBind id) }}} Swap the usage of `XIPBind` and `XCIPBind` [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow#Namingconve… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15327: Optimize remainders by powers of two for Integer and Natural
by GHC 02 Jul '18

02 Jul '18

#15327: Optimize remainders by powers of two for Integer and Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14437 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that GHC does not optimise `even (n :: Integer)` to a bitwise check, as it does for `Int` and `Word` (#14437). Here is a benchmark: {{{#!hs import Data.Time.Clock evenRem :: Integer -> Bool evenRem n = fromIntegral n `rem` 2 == (0 :: Word) lim :: Integer lim = 100000000 main :: IO () main = do t0 <- getCurrentTime print $ maximum $ filter even [1..lim] t1 <- getCurrentTime putStrLn "even" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ filter evenRem [1..lim] t1 <- getCurrentTime putStrLn "evenRem" print $ diffUTCTime t1 t0 }}} {{{ $ ghc -O2 Even.hs [1 of 1] Compiling Main ( Even.hs, Even.o ) Linking Even ... $ ./Even 100000000 even 6.367393s 100000000 evenRem 4.35664s }}} The reason is that `even (n :: Integer)` results in `remInteger` call in CMM, which remains unoptimized. One possible solution is to add a special case of divisor 2 to `GHC.Integer.Type.remInteger`. Or perhaps even something like {{{#!hs remInteger n (S# d#) | isPowerOfTwo (I# d#) = fromIntegral (fromIntegral n `rem` I# d#) isPowerOfTwo :: Int -> Bool isPowerOfTwo d = d /= 0 && d .&. (complement d + 1) == d }}} Since `remInteger` is not inlined during Core pipeline, such implementation of `even` will pattern-match in runtime, which is a bit suboptimal. On my machine it benchmarks halfway between `even` and `evenRem` above. Alternative approach is to add new rules to `PrelRules.builtinIntegerRules` to avoid any possible runtime slowdown. Is is appropriate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14529: Refactor ConDecl
by GHC 02 Jul '18

02 Jul '18

#14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The `ConDeclGADT` constructor in `ConDecl` is awful; all the information is buried. Refactor it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15283: Locale issue in the testsuite
by GHC 02 Jul '18

02 Jul '18

#15283: Locale issue in the testsuite -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With a French locale (LANG=fr_FR.utf-8), `make TEST=T14999` fails with: {{{#!patch End of assembler dump. -Contents of the .debug_frame section: +Contenu de la section .debug_frame : 00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16 LOC CFA rbp rsp ra }}} But it passes with `LANG=C make TEST=T14999`. Should we enforce the locale for the whole testsuite or only for this test? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13584: ghci parse error on operator info
by GHC 02 Jul '18

02 Jul '18

#13584: ghci parse error on operator info -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Keywords: parse, info, | Operating System: Linux operator | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If requested info about some operator, ie `(+)` `:info (+)` is working as expected: {{{#!haskell > :i (+) class Num a where (+) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 6 + }}} When additional space character is there `:info (+ )` it won't parse: {{{#!haskell > :i (+ ) <interactive>:1:3: error: parse error (possibly incorrect indentation or mismatched brackets) }}} Note that the same thing is working with `:type` so its strange it doesn't use the same parser here and there:ž {{{#!haskell > :t (+ ) (+ ) :: Num a => a -> a -> a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5