July 2018 - ghc-tickets

[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

[GHC] #12449: Broken types in identifiers bound by :print
by GHC 02 Jul '18

02 Jul '18

#12449: Broken types in identifiers bound by :print -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :print show show = (_t1::Show a => a -> String) Prelude> :t _t1 <interactive>:1:1: error: No instance for (Show a) arising from a use of ‘it’ }}} Furthermore: {{{#!hs Prelude> _t1 "foo" <interactive>:3:5: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: a_a1hz Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}} Enabling `-fprint-explicit-foralls`, I think, reveals the issue: {{{#!hs Prelude> :set -fprint-explicit-foralls Prelude> :print id id = (_t2::a1 -> a1) Prelude> :t id id :: forall {a}. a -> a Prelude> :t _t2 _t2 :: a1 -> a1 }}} Similar behavior albeit with a different panic message happens on 7.8.4 and 7.10.3 as verified by bennofs over IRC: {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :print print print = (_t1::Show a => a -> IO ()) Prelude> _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): tcTyVarDetails a_apc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} 7.6.3 doesn't exhibit this issue: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Prelude> :print id id = (_t1::forall a. a -> a) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15326: Add option to disable error message expression context (the 'In the expression' things)
by GHC 02 Jul '18

02 Jul '18

#15326: Add option to disable error message expression context (the 'In the expression' things) -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- A typical error looks like this: {{{ bug.hs:17:7: warning: [-Wdeferred-type-errors] ? No instance for (PolyList t0 [Integer]) arising from a use of ‘polyList’ ? In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^^^^^^^^^^^^^^^^^^ }}} Note the two lines starting with `In`. They waste two lines of error message space and now provides near zero utility since: 1. There's a caret view right below that context. 2. There are editor integrations that show squiggles right in the editor. Now we have an option `-f[no-]diagnostics-show-caret` that disables the caret. It would be great to have one that disables those code context lines too. As for naming. I'm thinking about `-f[no-]diagnostics-show-context`, which may be confused with constraint contexts, and `-f[no-]diagnostics-show- code-context`, which is a bit too long. I don't really know what those context lines are properly called, so maybe someone can come up with a more precise one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14553: Implement native CPP
by GHC 02 Jul '18

02 Jul '18

#14553: Implement native CPP -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Proposal/NativeCpp explains why we might want to embed a C-like preprocessor (e.g., hpp) into GHC. This ticket tracks that proposal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12410: Somehow detect splicing in ghci
by GHC 02 Jul '18

02 Jul '18

#12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | 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: -------------------------------------+------------------------------------- I'm no TH expert but currently it seems you need a hack (adding `data X ;` or `pure []`) to do the following {{{ ghci> $(reify ''() >>= runIO.print >> return []) <interactive>:210:3: error: • Couldn't match type ‘[t0]’ with ‘Exp’ Expected type: ExpQ Actual type: Q [t0] • In the expression: reify ''() >>= runIO . print >> return [] In the untyped splice: $(reify ''() >>= runIO . print >> return []) }}} {{{#!hs >>> data X; $(reify ''() >>= runIO.print >> return []) TyConI (DataD [] GHC.Tuple.() [] Nothing [NormalC GHC.Tuple.() []] []) >>> pure []; $(reify ''() >>= runIO.print >> return []) TyConI (DataD [] GHC.Tuple.() [] Nothing [NormalC GHC.Tuple.() []] []) }}} Same with [https://hackage.haskell.org/package/lens-4.14/docs/Control- Lens-TH.html#v:makeLenses makeLenses] (discussed [https://artyom.me/lens- over-tea-6 here], [https://github.com/ekmett/lens/issues/461 there]): {{{ >>> data A = B { _int :: Int } >>> makeLenses ''A <interactive>:209:1: error: • No instance for (Show DecsQ) arising from a use of ‘print’ • In a stmt of an interactive GHCi command: print it }}} the following two work {{{#!hs >>> data A = B { _int :: Int } >>> pure []; makeLenses ''A >>> view int (B 42) 42 }}} {{{#!hs >>> data A = B { _int :: Int }; makeLenses ''A >>> view int (B 42) 42 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7331: Allow the evaluation of declaration splices in GHCi
by GHC 02 Jul '18

02 Jul '18

#7331: Allow the evaluation of declaration splices in GHCi -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 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 monoidal): * related: #7331 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7331#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7331: Allow the evaluation of declaration splices in GHCi
by GHC 02 Jul '18

02 Jul '18

#7331: Allow the evaluation of declaration splices in GHCi -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7331 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * related: => #7331 Comment: See also #12410. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7331#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15225: `-fno-state-hack` produces incorrect results in nofib
by GHC 02 Jul '18

02 Jul '18

#15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #7411 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test. A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails: - Compile GHC from scratch with: {{{ GhcStage2HcOpts = -O -fno-state-hack GhcLibHcOpts = -O -fno-state-hack }}} - Run nofib with `EXTRA_HC_OPTS=-fno-state-hack` Doing this, the nofib test output is: {{{ ------------------------------------------------------------------------ == make all --no-print-directory; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta ------------------------------------------------------------------------ HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring RUNTEST_OPTS = -ghc-timing ==nofib== fasta: time to compile Main follows... /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc- timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o Main.hs:30:1: warning: [-Wtabs] Tab character found here, and in 13 further locations. Please use spaces instead. | 30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1)) | ^^^^^^^^ <<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>> ==nofib== fasta: size of Main.o follows... text data bss dec hex filename 7245 2624 0 9869 268d Main.o ==nofib== fasta: time to link fasta follows... <<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>> ==nofib== fasta: size of fasta follows... text data bss dec hex filename 708996 127712 16232 852940 d03cc fasta ==nofib== fasta: time to run fasta follows... ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; 0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k 0inputs+49656outputs (0major+608minor)pagefaults 0swaps ././fasta 2500000 < /dev/null expected stdout not matched by reality --- fasta.stdout 2018-06-02 03:00:43.887025433 +0200 +++ /tmp/runtest4673.1 2018-06-02 03:09:19.651755697 +0200 @@ -83337,333335 +83337,333335 @@ cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg -tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa -NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt -cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga -gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa -HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca #### ~3.1 million similar lines follow #### -taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt #### ~208k identical lines follow +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt taatagccgagagaaattac ../../mk/target.mk:101: recipe for target 'runtests' failed make[2]: *** [runtests] Error 1 Failed making all in fasta: 1 ../mk/ghc-recurse.mk:65: recipe for target 'all' failed make[1]: *** [all] Error 1 Failed making all in shootout: 1 mk/ghc-recurse.mk:65: recipe for target 'all' failed make: *** [all] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #4222: Template Haskell lets you reify supposedly-abstract data types
by GHC 02 Jul '18

02 Jul '18

#4222: Template Haskell lets you reify supposedly-abstract data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another possibility is to restrict what can be reified in the presence of the `Safe` language extension. To my knowledge, Template Haskell's ability to reify abstract names is precisely what makes `TemplateHaskell` imply `Unsafe`, so perhaps we could regain its safety by restricting what it can do in Safe Haskell. I agree that I wouldn't want to remove the ability to reify abstract names altogether, since there are many situations where that comes in handy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4222#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0