April 2017 - ghc-tickets

[GHC] Batch modify: #6087, #6132, #7273, #8763, #9221, #10141, #10536, ...
by GHC 06 Apr '17

06 Apr '17

Batch modification to #6087, #6132, #7273, #8763, #9221, #10141, #10536, #10640, #10770, #10789, #10853, #10878, #11092, #11197, #11204, #11259, #11260, #11323, #11359, #11369, #11392, #11474, #11495, #11587, #11634, #11686, #11719, #11721, #11749, #11765, #11827, #11836, #11954, #11955, #12021, #12038, #12075, #12090, #12193, #12369, #12388, #12517, #12581, #12599, #12619, #12636, #12652, #12669, #12712, #12714, #12715, #12737, #12765, #12774, #12808, #12825, #12875, #12926, #12932, #12934, #12937, #12938, #12940, #12949, #12962, #12964, #12999, #13003, #13069, #13078, #13080, #13090, #13092, #13093, #13165, #13182, #13226, #13280, #13346, #13390, #13471, #2725, #7723, #9249, #9981, #10582, #10930, #11091, #11958, #13001, #13064 by bgamari: milestone to 8.4.1 Comment: Given that 8.2.1-rc1 is imminent, I'm bumping these off to the 8.4 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=6087%2C6132%2C7273%2C8763%2C9221%2…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11544: SCC call-stack from `error` missing call-sites
by GHC 06 Apr '17

06 Apr '17

#11544: SCC call-stack from `error` missing call-sites -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- For some reason the `-prof` stack that `error` attaches only includes the top-level CAF. This is with the default build settings (which I believe are the release settings?) {{{ $ cat Foo.hs main = print (foo [1]) foo xs = tail (tail xs) $ ./inplace/bin/ghc-stage2 --make -prof -fprof-auto-calls Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) [flags changed] Linking Foo ... $ ./Foo Foo: Prelude.tail: empty list CallStack (from -prof): GHC.List.CAF (<entire-module>) }}} I would expect to at least see the call-site of `foo` (if not also `tail`) in the stack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13532: Work out better way of interacting with boot library upstreams
by GHC 06 Apr '17

06 Apr '17

#13532: Work out better way of interacting with boot library upstreams -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- Currently our protocol for tracking boot library upstreams is a bit painful. Namely, I periodically try updating the library submodules, typically all at once, and see what breaks. We then have to go about pushing various patches fixing the breakage. After a week or three when all of these patches are upstream we can try bumping the submodules again. Ideally nothing else has broken and we can push the result. However, let's just say that Murphy's law has an unfortunately truth to it. I wonder whether moving in the direction of what we currently do with `haddock` would be an improvement. Namely, we maintain a `ghc-head` branch of each of the libraries. We can then pull upstream in `master` and make fixes as necessary. These changes can then be asynchronously pushed upstream. In principle, we could even try pulling nightly to catch issues early. Of course, prior to a release we would ensure that `ghc-head` sat on a proper `master` commit. Anyways, I've been meaning to do something about this. Another task for post-8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 05 Apr '17

05 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Regarding comment:56, I don't think we would want to give every string literal the overhead of a full heap object. Even just adding a length as is proposed in this ticket is adding a significant binary size overhead for small strings, which occur quite often. The additional few words that a `ByteArray` closure would bring is far too expensive to stomach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 05 Apr '17

05 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Here's yet another proposal, I think we should compile string literals into `byteArray` using UTF8 encoding. I don't know if this is feasible, but this will make a universal `byteArray` based bytes library possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13486: inconsistency in handling the BOM Byte-order-mark in reading and putStrLn
by GHC 05 Apr '17

05 Apr '17

#13486: inconsistency in handling the BOM Byte-order-mark in reading and putStrLn -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- this is a very annoying issue and has been discussed already (e.g. #1744) and https://mail.haskell.org/pipermail/haskell- cafe/2011-January/088021.html. i think it is ok that the BOM character is not automatically removed when reading a file, but it is INCONSISTENT then to not show the BOM character when printing the file content. a minimal test: v <- readFile "fileWithBOM" putStrLn "the file content" putStrLn v putStrLn (show v) return () the first line does not indicate that there is a BOM character in the input and not removed from the result - only the second putStrLn (with the incorrect show on the result string) demonstrates the presence of the BOM character: "\65279\r\n.sprache English\r\n\..... consistency here is important to warn the programmer early on (after reading and checking file content) because other tools (e.g. parsec) see the BOM character and fail. i recommend that the BOM character is read but shown in printStrLn - i guess this is preferably over automatic (silent) removal. reading in and not showing, however, leads to misguided searches for strange errors caused by the BOM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences
by GHC 05 Apr '17

05 Apr '17

#13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Is there a difference between [https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List- NonEmpty.html#v:unfoldr Data.List.NonEmpty.unfoldr] and [https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List- NonEmpty.html#v:unfold Data.List.NonEmpty.unfold]? If there is a difference it would be nice to have that clarified in the docs -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13478> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 05 Apr '17

05 Apr '17

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Rev(s): Phab:D3404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 05 Apr '17

05 Apr '17

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Rev(s): Phab:D3404 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"af941a96f62101a6539f3cc35d82df3fd964539c/ghc" af941a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af941a96f62101a6539f3cc35d82df3fd964539c" Add regression test for #7944 Commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba happened to fix the bug reported in #7944. Let's add a regression test so that it stays that way. Fixes #7944. Test Plan: make test TEST=T7944 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3404 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible (was: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved)
by GHC 05 Apr '17

05 Apr '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Old description: > Building the included project with > {{{ > cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno- > code" > }}} > results in the following typechecker error: > {{{ > ByteCodeLink.lookupCE > During interactive linking, GHCi couldn't find the following symbol: > supabugzm0zi1zi0_A_makeLenseszq_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 > }}} New description: Building the included project with {{{ cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno- code" }}} results in the following typechecker error: {{{ ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: supabugzm0zi1zi0_A_makeLenseszq_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 }}} The problem here is that GHC goes looking for the code of modules needed for TemplateHaskell splices, which was not produced due to `-fno-code`. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0