December 2018 - ghc-tickets

[GHC] #15896: GHC API: add function to allow looking up Name for Located RdrName
by GHC 07 Dec '18

07 Dec '18

#15896: GHC API: add function to allow looking up Name for Located RdrName -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: GHC API | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5330 | Wiki Page: -------------------------------------+------------------------------------- A tool writer using the GHC API to do a source level change must use the `ParsedSource` as it most closely represents the original source code, and has API Annotations. But the `ParsedSource` only has `RdrName`s in it, and many useful transformations need information from the renamer, the simplest example being renaming a variable in the presence of name shadowing. So we need a way to look up the `Name` corresponding to each `RdrName` in the `ParsedSource`. GHC does have a `GlobalRdrEnv` which is a mapping from `OccName` to a list of elements, each of which has the `Name`. But the `OccName` is only unique wrt its spelling, and so cannot distinguish the name shadowing case. Fortuitously (!), every `RdrName` in the `ParsedSource` is `Located`, and hence has a unique `SrcSpan` associated with it. So, given a `TypecheckedModule`, it is possible to construct a map from the `SrcSpan` of each `Located RdrName` to the corresponding `Name` from the `RenamedSource` (or `TypecheckedSource` for ambiguous record selectors). Introduce this as part of the GHC API. Note: this function has existed in `HaRe` for some time, and is the reason each `RdrName` in the `ParsedSource` is `Located`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3
by GHC 07 Dec '18

07 Dec '18

#13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3 -------------------------------------+------------------------------------- Reporter: ppelleti | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using [https://github.com/ppelleti/hs-mercury-api this package], I tried doing "stack repl" with GHC 8.0.2: {{{ whiteandnerdy:hs-mercury-api ppelleti$ stack repl The following GHC options are incompatible with GHCi and have not been passed to it: -threaded * * * * * * * * The main module to load is ambiguous. Candidates are: 1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr- firmware.hs 2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs 3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs 4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs 5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs 6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs You can specify which one to pick by: * Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr- firmware * Specifying what the main is e.g. stack ghci --main-is mercury-api:exe :tmr-firmware * Choosing from the candidate above [1..6] * * * * * * * * Specify main module to use (press enter to load none): 4 Loading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs Configuring GHCi with the following packages: mercury-api GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This bug appears to have been around a while, because it also happens with GHC 7.8.3: {{{ whiteandnerdy:hs-mercury-api ppelleti$ cabal repl Preprocessing library mercury-api-0.1.0.0... GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package text-1.2.2.1 ... linking ... done. Loading package hashable-1.2.6.0 ... linking ... done. Loading package unordered-containers-0.2.8.0 ... linking ... done. Loading package clock-0.7.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package ansi-terminal-0.6.2.3 ... linking ... done. Loading object (static) dist/build/cbits/api/tmr_strerror.o ... done Loading object (static) dist/build/cbits/api/tmr_param.o ... done Loading object (static) dist/build/cbits/api/hex_bytes.o ... done Loading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm using Mac OS X 10.9.5: {{{ whiteandnerdy:hs-mercury-api ppelleti$ uname -a Darwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables
by GHC 07 Dec '18

07 Dec '18

#15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: TypeFamilies | 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 following code typechecks on GHC HEAD (8.7+): {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind class C1 a where type T1 a b class C2 a where type T2 a b instance C1 (Maybe a) where type forall a b. T1 (Maybe a) b = b instance C2 (Maybe a) where type forall b. T2 (Maybe a) b = b }}} But ought it to? There is something funny happening in the `C1` instance: it's explicitly quantifying `a`, despite the fact that it had previously been quantified by the class head! Moreover, it appears that you can safely drop the `a` in the explicit `forall`, as the `C2 (Maybe a)` instance witnesses. What does the documentation have to say on this topic? This is all I could find: > When an explicit `forall` is present, all //type// variables mentioned must be bound by the `forall`. I couldn't find anything on the interaction between this feature and associated type families. We should: 1. Decide which of the two programs above should be accepted, and 2. Update the documentation to reflect this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15951: Hadrian test doesn't show testsuite output by default
by GHC 07 Dec '18

07 Dec '18

#15951: Hadrian test doesn't show testsuite output by default -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (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: -------------------------------------+------------------------------------- When running `hadrian test` the user sees no indication that the build system is actually doing anything beyond the furious whirring of their CPU fan. Once the testsuite finishes Hadrian kindly informs the user that the testsuite passed or failed, but provides no additional feedback on what failed or where the output can be found. We should just print all testsuite output to stdout, as the `make` build system does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15263: Fuse zipWith3
by GHC 06 Dec '18

06 Dec '18

#15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I was surprised to discover that `zipWith3` has no `RULES` associated with it to aid fusion. Can we add these? I have no idea what I'm doing, but would this substitution work: {{{ {-# RULES "zipWith3" zipWith3 f a b c = zipWith id (zipWith f a b) c #-} }}} Those who know what they're doing will likely devise a better strategy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible
by GHC 06 Dec '18

06 Dec '18

#15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't understand what's going wrong here. {{{#!hs -- Fishy.hs {-# language RankNTypes, QuantifiedConstraints, RoleAnnotations #-} module Fishy (Yeah, yeahCoercible) where import Data.Coerce data Yeah_ a = Yeah_ Int newtype Yeah a = Yeah (Yeah_ a) type role Yeah representational yeahCoercible :: ((forall a b. Coercible (Yeah a) (Yeah b)) => r) -> r yeahCoercible r = r -- Fishy2.hs module Fishy2 where import Fishy import Data.Type.Coercion import Data.Coerce yeah :: Coercion [Yeah a] [Yeah b] yeah = yeahCoercible Coercion }}} I get {{{ Fishy2.hs:8:22: error: • Couldn't match representation of type ‘a’ with that of ‘b’ arising from a use of ‘Coercion’ ‘a’ is a rigid type variable bound by the type signature for: yeah :: forall a b. Coercion [Yeah a] [Yeah b] at Fishy2.hs:7:1-34 ‘b’ is a rigid type variable bound by the type signature for: yeah :: forall a b. Coercion [Yeah a] [Yeah b] at Fishy2.hs:7:1-34 • In the first argument of ‘yeahCoercible’, namely ‘Coercion’ In the expression: yeahCoercible Coercion In an equation for ‘yeah’: yeah = yeahCoercible Coercion • Relevant bindings include yeah :: Coercion [Yeah a] [Yeah b] (bound at Fishy2.hs:8:1) | 8 | yeah = yeahCoercible Coercion | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 06 Dec '18

06 Dec '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15525 | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I'm going to punt this to 8.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16005: Don't use a generic apply thunk for known calls
by GHC 06 Dec '18

06 Dec '18

#16005: Don't use a generic apply thunk for known calls -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5414 | Wiki Page: -------------------------------------+------------------------------------- Currently, an AP thunk like `sat = f a b c` will not have its own entry point and info pointer and will instead reuse a generic apply thunk like `stg_ap_4_upd`. That's great from a code size perspective, but if `f` is a known function, a specialised entry point with a plain call can be much faster than figuring out the arity and doing dynamic dispatch. ---- I prepared a patch over at Phab:D5414 that fixes this by checking if the arity of `f` is unknown (e.g. 0). If not, it will no longer delegate to a generic apply thunk and generate regular entry code and info tables instead. No impact on allocations, but on counted instructions and code size. Significant changes to counted instructions: ||cryptarithm1 || -2.5%|| ||lcss || -2.3%|| ||paraffins || -3.8%|| ||wheel-sieve2 || -3.4%|| |||||| ||Min || -3.8%|| ||Max || +0.0%|| || Geometric Mean || -0.2%|| And changes to binary size greater than 0.1% (all the other programs, basically): || Program ||Size || Instrs|| || anna ||+0.3% ||-0.2%|| || expert ||+0.2% ||-0.0%|| || fluid ||+0.2% ||-0.1%|| || grep ||+0.2% ||-0.0%|| || infer ||+0.2% ||-0.4%|| || last-piece ||+0.2% ||-0.1%|| || lift ||+0.2% ||-0.0%|| || paraffins ||+0.2% ||-3.8%|| || prolog ||+0.2% ||-0.1%|| || scs ||+0.3% ||-0.0%|| || transform ||+0.2% ||-0.2%|| || veritas ||+0.2% ||+0.0%|| |||||||| || Min ||+0.1% ||-3.8%|| || Max ||+0.3% ||+0.0%|| || Geometric Mean ||+0.1% ||-0.2%|| -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity
by GHC 06 Dec '18

06 Dec '18

#15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This bug report is about the incorrect result not the poor performance.) Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64): {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e100000000 :: Double Infinity (5.70 secs, 68,552 bytes) Prelude> 1e1000000000 :: Double 0.0 (69.35 secs, 60,088 bytes) }}} Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases. More precisely, {{{ Prelude> 1e646457008 :: Double Infinity (40.80 secs, 64,272 bytes) Prelude> 1e646457009 :: Double 0.0 (40.46 secs, 60,088 bytes) }}} Note: {{{#!hs (floor $ 2^31 / logBase 2 10 + 16) == 646457009 }}} This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?). Standalone test program: {{{#!hs main = do print 1e646457008 print 1e646457009 }}} Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help). {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e646457008 :: Double Infinity (415.26 secs, 17,908 bytes) Prelude> 1e646457009 :: Double Infinity (417.66 secs, 17,820 bytes) Prelude> 1e746457298 :: Double Infinity (490.00 secs, 17,820 bytes) Prelude> 1e1000000000 :: Double GNU MP: Cannot allocate memory (size=419438600) Aborted $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15894: Cannot find symbol during interactive linking using new-repl on Windows
by GHC 06 Dec '18

06 Dec '18

#15894: Cannot find symbol during interactive linking using new-repl on Windows --------------------------------------+---------------------------- Reporter: YellPika | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- Originally from https://github.com/haskell/cabal/issues/5683. I get the following error on Windows 10: {{{ > cabal new-repl --build-depends=ieee754 ... GHCi loads ... Prelude> import Numeric.IEEE Prelude Numeric.IEEE> infinity ghc.exe: | C:\Users\Anthony\AppData\Roaming\cabal\store\ghc-8.6.2\ieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266\lib\libHSieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266.a: unknown symbol `copysign' ghc.exe: ^^ Could not load 'ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure', dependency unresolved. See top entry above. ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} This occurs with both cabal-install 2.4.0.0 and HEAD. This does not occur if I install ieee754 into a sandbox and use `cabal repl`. It also works correctly on Ubuntu 18.04 (on both WSL and a full installation), so it looks like a Windows-specific problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4