November 2016 - ghc-tickets

[GHC] #12795: Add more types to System.Posix.Types
by GHC 15 Jan '17

15 Jan '17

#12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 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: -------------------------------------+------------------------------------- A whole lot of types are still missing from `System.Posix.Types` as noted in a TODO comment in the code: {{{ --- ToDo: blksize_t, clockid_t, blkcnt_t, fsblkcnt_t, fsfilcnt_t, id_t, key_t --- suseconds_t, timer_t, useconds_t }}} Specifically the lack of wrappers for blkcnt_t is causing trouble because it's forcing HFuse to re-implement `unix`'s `FileStatus` type to include the missing `st_blocks` field. See [https://hackage.haskell.org/package/HFuse/docs/System- Fuse.html#t:FileStat FileStat docs on Hackage]. I have patches for `base` and `unix` ready to add wrappers for all the types the comment mentions, let's see if I can figure out how to use Phab ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10073: Idris REPL is pretty and we can too
by GHC 14 Jan '17

14 Jan '17

#10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Manual for configuring colors in the Idris REPL: https://github.com/idris- lang/Idris-dev/wiki/Manual#colours Screenshot: http://i.imgur.com/rYHCI4T.png Particularly, I'd like to make type errors and warnings more visually distinct. I think little touches like this can go a long way to making it nice to work with Haskell code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12766: Allow runtime-representation polymorphic data families
by GHC 14 Jan '17

14 Jan '17

#12766: Allow runtime-representation polymorphic data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an offshoot of #12369 (‘ data families shouldn't be required to have return kind *, data instances should’), allowing family declarations something like: {{{#!hs data family Array a :: TYPE rep }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12622: Unboxed static pointers lead to missing SPT entries
by GHC 13 Jan '17

13 Jan '17

#12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: facundominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I found what appears to be a regression following the merge of the new FloatOut based static pointers support. See github.com/mboes/bug-ptr-not- in-spt for a fully developed minimal example. It seems to be quite hard to trigger this bug: * I need to be using distributed-closure (not bare `StaticPtr`). * The static pointer needs to be defined in a separate module. * The static pointer must refer to a value with at least one polymorphic argument. * Compiler optimization level 1 needs to be turned on. At any rate, I wasn't able to trigger it without all conditions above being true. Initial investigations by facundominguez point to static pointer unpacking in distributed-closure as the culprit. Likely unpacked static pointers are no longer recognized as such by the FloatOut pass and therefore never floated to top-level, hence breaking a fundamental invariant about static pointers. This might explain why sometimes static pointers don't get added to the static pointer table (SPT), as in the above minimal example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12090: Document Weverything/Wall/Wextra/Wdefault in user's guide
by GHC 13 Jan '17

13 Jan '17

#12090: Document Weverything/Wall/Wextra/Wdefault in user's guide -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Keywords: warnings | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: Design/Warnings -------------------------------------+------------------------------------- The user's guide needs to be updated to reflect the feature implemented in phab:D1850 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences
by GHC 12 Jan '17

12 Jan '17

#11695: On GHCi prompt the arrow (movement) keys create strange character sequences --------------------------------------+--------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Fire up `GHCi` and sit on the arrow down (or left) keys. This is what I get after constantly pressing for some time: {{{ $ ghci GHCi, version 8.1.20160202: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ggreif/.ghci Prelude> OBOBOBBOBOBOBOBOBOBOBCOCCOCOCCOCCOC <interactive>:1:1: error: Data constructor not in scope: OBOBOBBOBOBOBOBOBOBOBCOCCOCOCCOCCOC }}} When such a strange letter appears, there is also a blinking of the terminal. It is not happening on Windows. I have seen it on RHEL5 and RHEL6. Pretty annoying, especially when you want to quickly navigate in the repl. This is probably a `haskeline` bug, but I am coming here to see whether others suffer from it too, i.e. is it reproducible for elseone? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11695> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11781: Improve common sub-expression
by GHC 12 Jan '17

12 Jan '17

#11781: Improve common sub-expression -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2074 | Wiki Page: -------------------------------------+------------------------------------- I wrote a patch that refactors and improves the CSE pass. It's in `wip/cse-code-desmelling`, and Phab:D2074 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10083: ghc: panic! (the 'impossible' happened)
by GHC 12 Jan '17

12 Jan '17

#10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I used hprotoc to generate some code for Google protocol buffers. The QueryValue.proto file is attached. You can install hprotoc tool using cabal. then use ''hprotoc QueryValue.proto'' to generate code. Then create a minimal cabal file. ''cabal init -m --is-library -n'' Then if you build it with '''optimization enabled''', the build will fail ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sEMq{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 59242 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8.
by GHC 12 Jan '17

12 Jan '17

#12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ----------------------------------------+--------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I encountered the "Simplifier ticks exhausted" error when compiling some code generated by hprotoc in GHC 8.0.1. It works with -O0, but fails with -O1. The code compiles successfully with GHC 7.10, but fails with 8.0.1. Specifying a larger value for 'simpl-tick-factor' doesn't seem to help. The original code was generated by hprotoc, but a much simplified version is attached. Here is the output with '-ddump-simpl-stats' enabled: {{{ stack build cycle-test --ghc-options -ddump-simpl-stats cycle-test-0.1.0.0: configure Configuring cycle-test-0.1.0.0... cycle-test-0.1.0.0: build Preprocessing library cycle-test-0.1.0.0... [1 of 4] Compiling Thing2[boot] ( src/Thing2.hs-boot, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Thing2.o-boot ) [2 of 4] Compiling Thing1 ( src/Thing1.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Thing1.o ) [3 of 4] Compiling Thing2 ( src/Thing2.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Thing2.o ) [4 of 4] Compiling Box ( src/Box.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Box.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $fxEqThing2 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed Total ticks: 6442 1681 PreInlineUnconditionally 280 $dEq_a1AB 280 ds_a1AC 280 ds_i28z 280 ds1_i28A 279 ds_i29a 279 ds1_i29b 1 ds_a1As 1 ds_d28r 1 ds_d28s 280 PostInlineUnconditionally 280 ds1_a1AD 1120 UnfoldingDone 280 $fEqMaybe_$c== 280 $fEqThing1_$c== 279 $fxEqThing2 279 $fEqThing2_$c== 1 $c==_a289 1 not 279 RuleFired 279 Class op == 2241 BetaReduction 280 a_a1AA 280 $dEq_a1AB 280 ds_a1AC 280 ds1_a1AD 280 ds_i28z 280 ds1_i28A 279 ds_i29a 279 ds1_i29b 1 ds_a1As 1 ds_d28r 1 ds_d28s 1 CaseOfCase 1 wild_a1At 840 KnownBranch 840 wild_a1At }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10262: Improve documentation of module signatures
by GHC 11 Jan '17

11 Jan '17

#10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Operating System: Unknown/Multiple Keywords: backpack | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Out of curiosity, I read the bit in the user manual about the new module signatures, and I find the text a little confusing. Could those in the know clarify the points below in the manual? Thanks! * (typo) The first example refers to `String.hs`. I think you mean `Text.hs`. * Is there a way to use module signatures to deal with mutually recursive modules? The example with `TextSig` seems to require that both `Text` and `TextSig` are compiled before `A`. * Could you provide an example of specifying multiple signature/implementation pairs with `--make`? * The manual says that the dialect of Haskell used in signature files is "essentially" the same as with hs-boot files. Are there any differences? * The most recent paragraph addition doesn't make sense to me, starting with "Signatures can be installed like ordinary modules". What do you mean by "installed"? What does it mean to bring multiple signatures into scope by the same name? Can two signatures have the same name? Wouldn't their filenames also need to be the same? * Is there currently any facility available to have multiple implementations of one signature? Of course, this is all work in progress, and I don't necessarily expect an immediate fix. But, when it's nearing completion, it may be worth revisiting this stretch of text. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5