June 2015 - ghc-tickets

[GHC] #10529: hpc: Improve error messages in readMix
by GHC 20 Jul '15

20 Jul '15

#10529: hpc: Improve error messages in readMix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Code | Version: 7.10.1 Coverage | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://hackage.haskell.org/package/hpc-0.6.0.2/docs/src/Trace-Hpc- Mix.html#readMix The generic `error $ "can not find " ++ modName ++ " in " ++ show dirNames` error message is used for all kinds of cases, for example when `h == tixModuleHash tix` isn't true. It would be very helpful if the error message could be specific for these cases (e.g. "hashes don't agree") instead of being a catch-all for all `Nothing`s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10094: Template Haskell cannot represent type wildcards
by GHC 20 Jul '15

20 Jul '15

#10094: Template Haskell cannot represent type wildcards -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There does not appear to be a way for Template Haskell code to generate partial type signature wildcards. The type quasiquote `[t|_|]` results in `Wildcard not allowed`, and use in an expression quasiquote like `[|() :: _|]` results in `Exotic form of type not (yet) handled by Template Haskell _`. It would be useful if TH code could partially constrain the type of the expressions it was generating, without needing to determine the type completely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird
by GHC 20 Jul '15

20 Jul '15

#10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- {{{ $ for i in `seq 10`; do echo "print $i" > /tmp/$i.ghci; done $ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci 2 1 0 $ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci -ignore-dot- ghci 0 }}} `-ghci-script` are executed in reverse order and are ignored when `-ignore-dot-ghci` is specified, while I expected that: * `-ghci-script` are executed in the order they are specified; * `-ignore-dot-ghci` only ignores the default .ghci files but still executes the scripts passed by `-ghci-script`. I would like to change the behavior to the expected ones. But in case there are users relying on the old behavior, then it might be necessary to introduce different flags. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm
by GHC 19 Jul '15

19 Jul '15

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Test case (#7571 just will not die, it seems) {{{ $ make TEST=T7571 WAY=llvm ... ====> Scanning ./all.T =====> T7571(llvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -fllvm -no-hs-main >T7571.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-07 22:18:14.132934017 -0500 +++ ./T7571.comp.stderr 2013-08-14 01:26:33.942103723 -0500 @@ -0,0 +1 @@ +WARNING: Non constant alignment value given for memcpy! Please report to GHC developers *** unexpected failure for T7571(llvm) }}} However, this test case does not fail under WAY=optllvm, which I think is worth investigating probably: {{{ $ make TEST=T7571 WAY=optllvm ... ====> Scanning ./all.T =====> T7571(optllvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -O -fllvm -no-hs-main >T7571.comp.stderr 2>&1 OVERALL SUMMARY for test run started at Wed Aug 14 01:25:42 CDT 2013 7 total tests, which gave rise to 28 test cases, of which 27 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures }}} However, there is another way to trigger this bug in *both* cases: {{{ #include "Cmm.h" testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { prim %memcpy(dst, src, l, sz); return (); } }}} will fail both ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10578: ghci line numbers are off by one
by GHC 19 Jul '15

19 Jul '15

#10578: ghci line numbers are off by one -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> 3 : 'a' <interactive>:2:5: Couldn't match expected type ‘[a]’ with actual type ‘Char’ Relevant bindings include it :: [a] (bound at <interactive>:2:1) In the second argument of ‘(:)’, namely ‘'a'’ In the expression: 3 : 'a' In an equation for ‘it’: it = 3 : 'a' Prelude> 3 : 'a' <interactive>:3:5: Couldn't match expected type ‘[a]’ with actual type ‘Char’ Relevant bindings include it :: [a] (bound at <interactive>:3:1) In the second argument of ‘(:)’, namely ‘'a'’ In the expression: 3 : 'a' In an equation for ‘it’: it = 3 : 'a' Prelude> }}} Why are the errors reported as being on lines 2 and 3? And no, I don't buy that line 1 was the GHCi welcome message :) Apparently it's been like this since at least GHC 7.4 and I've never noticed. `ghc -e cmd1 -e cmd2` reports every command as beginning on a new line 1, which is also weird. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9571: nofib should use criterion-style bootstrapping/sampling
by GHC 19 Jul '15

19 Jul '15

#9571: nofib should use criterion-style bootstrapping/sampling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.9 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As I discovered when investigating situations like #9570, in some cases, test-cases in nofib are giving nonsense, and it's hard to tell unless you run nofib several times and notice that percentage differences are fluctuating up and down. The quality of the numbers we get for uninformed users would be better if we ran some statistical analysis to tell how many times to run the benchmark, and if there were lots of outliers (rather than just blindly summarizing all the runs using an average.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8123: GHCi warns about -eventlog even though it's sometimes necessary
by GHC 19 Jul '15

19 Jul '15

#8123: GHCi warns about -eventlog even though it's sometimes necessary -------------------------+------------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: GHCi | Operating System: Linux Keywords: | Type of failure: Incorrect warning at Architecture: | compile-time x86_64 (amd64) | Test Case: Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- If I invoke GHCi as {{{ghci -eventlog}}}, it says: {{{Warning: -debug, -threaded and -ticky are ignored by GHCi}}}. However, the flag does make a difference, in that GHCi will be able to load object files that were compiled using {{{-eventlog}}}. For this reason, I don't think {{{-eventlog}}} should trigger the warning. Also runghc has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10224: Partial type signatures generate typed hole warnings
by GHC 17 Jul '15

17 Jul '15

#10224: Partial type signatures generate typed hole warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHCi generates typed hole warnings in type signatures even when PartialTypeSignatures is enabled: {{{ > :set -XPartialTypeSignatures > :t (==) :: Char -> _ <interactive>:1:17: Warning: Found hole ‘_’ with type: Char -> Bool In an expression type signature: Char -> _ In the expression: (==) :: Char -> _ (==) :: Char -> _ :: Char -> Char -> Bool > :set -XNoPartialTypeSignatures > :t (==) :: Char -> _ <interactive>:1:17: Found hole ‘_’ with type: Char -> Bool To use the inferred type, enable PartialTypeSignatures In an expression type signature: Char -> _ In the expression: (==) :: Char -> _ }}} Similarly, GHC 7.10.1, when given the following source, {{{ {-# LANGUAGE PartialTypeSignatures #-} f = (==) :: Char -> _ main = return () }}} mentions that it "found a hole". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface
by GHC 17 Jul '15

17 Jul '15

#9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface -------------------------+------------------------------------------------- Reporter: | Owner: ezyang | Status: new Type: bug | Milestone: Priority: | Version: 7.9 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date. However, this does not currently work: we always re-typecheck: {{{ t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) }}} The reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on "linkables" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck. However, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't). The upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now. Related to https://github.com/haskell/cabal/issues/1179 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9618: Undocument ImpredicativeTypes
by GHC 16 Jul '15

16 Jul '15

#9618: Undocument ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I understand that Simon Peyton Jones intends to make `ImpredicativeTypes` work some day, but it doesn't work now. I think the thing to do for now is to remove it from the user manual. It can be put back in later if it's ever fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4