October 2014 - ghc-tickets

[GHC] #9256: Support automatic derivation of an hs-boot file from an hs file
by GHC 24 Jul '15

24 Jul '15

#9256: Support automatic derivation of an hs-boot file from an hs file ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is essentially augustss's proposal from ticket #1409: I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., Replying to [comment:13 augustss]: > I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., > > {{{ > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > data T = ... > foo :: ... > foo = ... > }}} > > The values that have an annotation would have to have a type signature. This should be eminently doable. Here is a more fleshed out proposal. First, consider the definition of an hs-boot file in the absence of mutual recursion (i.e. no breakers are necessary). In this case, the hi-boot file for an hs file is precisely the hi file produced after ordinary renaming and typechecking of the module. As an optimization, we would like to avoid typechecking definitions if an explicit type signature is present (if the type signature is absent, we have no choice.) There are a few choices here: we can force users to give top-level declarations for all exported functions (so unconditionally error if something is missing, by filtering out the relevant value declarations from the source), or we can go ahead and do full typechecking when the signature is missing. (The former is probably the simplest.) Now, how to handle breakers? We need to avoid typechecking them, since their recursive dependence means that they would not type check properly. So we should also filter out their type signatures. (Furthermore, if we are inferring some signatures, we need to make sure that their definitions don't rely on any breakers. For this reason, it is probably simplest to just require explicit type signatures.) If the mechanism for specifying breakers is exclusionary (as opposed to an inclusionary method of saying what values are in the signature), there is an awkward problem of syntax for exporting only an abstract type: the logical choices mean the wrong thing (`T(..)` seem to imply the type is eliminated entirely, whereas `T` seems to imply that the type should be eliminated, but not eh constructors.) Summary: 1. Require top-level signatures in hs to hs-boot files(?) 2. Exclusionary or inclusionary signature pragma? 3. Filter out value declarations and excluded files, then rename/typecheck as normal, producing hi-boot file -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9256> 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 20 Jul '15

20 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] #9571: nofib should use criterion-style bootstrapping/sampling
by GHC 20 Jul '15

20 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 20 Jul '15

20 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] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface
by GHC 18 Jul '15

18 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 17 Jul '15

17 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

[GHC] #8709: `make 1` does not work (well)
by GHC 11 Jul '15

11 Jul '15

#8709: `make 1` does not work (well) ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: | ------------------------------------+------------------------------------- Say I do a `sync-all pull` and then fix a bunch of merge errors. The changes mean that I need to recompile the stage-1 compiler. So, I dutifully `make distclean` and start rebuilding. I then find a bunch of compiler errors in my edited code. Now, I'd like to start the fix error/recompile loop. BUT, when I do `make 1` in the `compiler/` directory, I get errors: {{{ rae:13:49:29 ~/Documents/ghc/compiler> make 1 make -C .. stage=1 all_ghc_stage1 compiler_dist_NO_BUILD_DEPS=YES compiler_dist-boot_NO_BUILD_DEPS=YES compiler_dist- install_NO_BUILD_DEPS=YES NO_GENERATED_MAKEFILE_RULES=YES OMIT_PHASE_0=YES OMIT_PHASE_1=YES compiler_stage1_NO_BUILD_DEPS=YES compiler_stage2_NO_BUILD_DEPS=YES compiler_stage3_NO_BUILD_DEPS=YES ghc_stage1_NO_BUILD_DEPS=YES ghc_stage2_NO_BUILD_DEPS=YES ghc_stage3_NO_BUILD_DEPS=YES ONLY_DEPS_FOR="compiler_stage1 ghc_stage1" ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_ghc_stage1 libraries/old-time/ghc.mk:5: libraries/old-time/dist-install/package- data.mk: No such file or directory libraries/haskell98/ghc.mk:5: libraries/haskell98/dist-install/package- data.mk: No such file or directory libraries/haskell2010/ghc.mk:5: libraries/haskell2010/dist-install /package-data.mk: No such file or directory libraries/random/ghc.mk:5: libraries/random/dist-install/package-data.mk: No such file or directory libraries/primitive/ghc.mk:5: libraries/primitive/dist-install/package- data.mk: No such file or directory libraries/vector/ghc.mk:5: libraries/vector/dist-install/package-data.mk: No such file or directory libraries/dph/dph-base/ghc.mk:5: libraries/dph/dph-base/dist-install /package-data.mk: No such file or directory libraries/dph/dph-prim-interface/ghc.mk:5: libraries/dph/dph-prim- interface/dist-install/package-data.mk: No such file or directory libraries/dph/dph-prim-seq/ghc.mk:5: libraries/dph/dph-prim-seq/dist- install/package-data.mk: No such file or directory libraries/dph/dph-prim-par/ghc.mk:5: libraries/dph/dph-prim-par/dist- install/package-data.mk: No such file or directory libraries/dph/dph-lifted-base/ghc.mk:5: libraries/dph/dph-lifted-base /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-boxed/ghc.mk:5: libraries/dph/dph-lifted-boxed /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-copy/ghc.mk:5: libraries/dph/dph-lifted-copy /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-vseg/ghc.mk:5: libraries/dph/dph-lifted-vseg /dist-install/package-data.mk: No such file or directory libraries/ghc-prim/ghc.mk:4: libraries/ghc-prim/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/ghc.mk:4: libraries/integer-gmp/dist-install /package-data.mk: No such file or directory libraries/base/ghc.mk:4: libraries/base/dist-install/package-data.mk: No such file or directory libraries/filepath/ghc.mk:4: libraries/filepath/dist-install/package- data.mk: No such file or directory libraries/array/ghc.mk:4: libraries/array/dist-install/package-data.mk: No such file or directory libraries/deepseq/ghc.mk:4: libraries/deepseq/dist-install/package- data.mk: No such file or directory libraries/bytestring/ghc.mk:4: libraries/bytestring/dist-install/package- data.mk: No such file or directory libraries/containers/ghc.mk:4: libraries/containers/dist-install/package- data.mk: No such file or directory libraries/old-locale/ghc.mk:4: libraries/old-locale/dist-install/package- data.mk: No such file or directory libraries/time/ghc.mk:4: libraries/time/dist-install/package-data.mk: No such file or directory libraries/unix/ghc.mk:4: libraries/unix/dist-install/package-data.mk: No such file or directory libraries/directory/ghc.mk:4: libraries/directory/dist-install/package- data.mk: No such file or directory libraries/process/ghc.mk:4: libraries/process/dist-install/package- data.mk: No such file or directory libraries/hpc/ghc.mk:4: libraries/hpc/dist-install/package-data.mk: No such file or directory libraries/pretty/ghc.mk:4: libraries/pretty/dist-install/package-data.mk: No such file or directory libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist- install/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:4: libraries/Cabal/Cabal/dist-install /package-data.mk: No such file or directory libraries/binary/ghc.mk:4: libraries/binary/dist-install/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:4: libraries/bin-package-db/dist-install /package-data.mk: No such file or directory libraries/hoopl/ghc.mk:4: libraries/hoopl/dist-install/package-data.mk: No such file or directory libraries/transformers/ghc.mk:4: libraries/transformers/dist-install /package-data.mk: No such file or directory libraries/xhtml/ghc.mk:4: libraries/xhtml/dist-install/package-data.mk: No such file or directory libraries/terminfo/ghc.mk:4: libraries/terminfo/dist-install/package- data.mk: No such file or directory libraries/haskeline/ghc.mk:4: libraries/haskeline/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/gmp/ghc.mk:49: libraries/integer-gmp/gmp/config.mk: No such file or directory utils/hsc2hs/ghc.mk:16: utils/hsc2hs/dist-install/package-data.mk: No such file or directory utils/ghc-pkg/ghc.mk:66: utils/ghc-pkg/dist-install/package-data.mk: No such file or directory utils/dll-split/ghc.mk:18: utils/dll-split/dist-install/package-data.mk: No such file or directory utils/ghc-pwd/ghc.mk:8: utils/ghc-pwd/dist-install/package-data.mk: No such file or directory utils/ghc-cabal/ghc.mk:67: utils/ghc-cabal/dist-install/package-data.mk: No such file or directory utils/hpc/ghc.mk:18: utils/hpc/dist-install/package-data.mk: No such file or directory utils/runghc/ghc.mk:28: utils/runghc/dist-install/package-data.mk: No such file or directory utils/mkUserGuidePart/ghc.mk:18: utils/mkUserGuidePart/dist/package- data.mk: No such file or directory utils/compare_sizes/ghc.mk:8: utils/compare_sizes/dist-install/package- data.mk: No such file or directory make[2]: *** No rule to make target `libraries/integer-gmp/gmp/config.mk'. Stop. make[1]: *** [all_ghc_stage1] Error 2 make: *** [1] Error 2 }}} Using `make stage=1` works fine, but computing the dependencies each time is annoying. In past experience, I've seen that, once the stage-1 compiler builds to completion at least once, `make 1` works just fine -- it just fails after a `clean`. I don't recall having this problem with `make 2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide
by GHC 07 Jul '15

07 Jul '15

#9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: task | Status: new Priority: high | Milestone: Component: Documentation | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If one wants to support older versions of GHC, it is hard to find out whether one can use a certain LANGUAGE extension. One has to go to older versions of the GHC manual to find out whether the corresponding documentation was already there, or browse release notes. Requests: 1. Document for new LANGUAGE extensions that they are available since version 7.10. For example, by adding "(Since GHC 7.10)" to the heading of the new feature. 2. Do this also for the previous LANGUAGE extensions, by adding e.g., "(Since GHC 7.6)" etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8206: Add support for Portable Native Client
by GHC 05 Jul '15

05 Jul '15

#8206: Add support for Portable Native Client -------------------------------------------------+------------------------- Reporter: guest | Owner: Alex Type: feature request | Sayers Priority: normal | Status: new Component: Compiler | Milestone: Keywords: NaCl PNaCl Portable Native | Version: Client pexe | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- == Motivation == [http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable- native-client Portable Native Client] (PNaCl) is a feature in Google Chrome which (roughly) allows it to use LLVM bitcode like browsers use javascript today. The bitcode is downloaded, validated, compiled, and (safely) executed, with access to an API for manipulating the DOM of the page which loaded it. The dream: Haskell executed in the browser at near- native speed. Unfortunately, while GHC has an LLVM backend, the bitcode it generates doesn't satisfy the PNaCl validator. == Portable Native Client == The user visits a page with an <embed> tag pointing to a "pexe" - a PNaCl bitcode file. The bitcode is downloaded and streamed first into a code validator, and then into a compiler. The resulting machine code is then executed as a memory-protected process. The [https://developers.google.com /native-client/pepperc/ Pepper API], a library Google provides, provides access to the browser for things like connecting to websockets, playing audio, and communicating with javascript running on the page. PNaCl is present in Chrome 29 (go to chrome://flags to enable it), and will be enabled for arbitrary sources (the "open web") in Chrome 30. Mozilla have announced that they don't intend to support Native Client. == The Easily-Fixed == The pexe bitcode format is a frozen subset of LLVM bitcode. The PNaCl toolchain provides `pnacl-finalize`, which translates LLVM bitcode into pexe bitcode. PNaCl [http://www.chromium.org/nativeclient/pnacl/bitcode- abi##callingconventions only allows] the standard "ccc" calling convention, whereas GHC likes to use its own "cc 10" calling convention. You can make GHC use ccc by using an unregisterised build, for a slow-down factor of about 2. It seems likely that code-next-to-tables will upset the validator. If so, this can be turned off for a small performance hit. == The Not-So-Easily-Fixed == The validator requires that requests for IO are sent to Pepper. PNaCl also requires that you use newlib instead of glibc. Spawning new processes is forbidden (although creating pthreads is fine). It also seems likely that the validator with take umbrage at calls to `mmap`, which the GHC runtime uses to request memory allocation. It seems, therefore, that significant chunks of the RTS will have to be ported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8353: Easy way to defer type errors
by GHC 05 Jul '15

05 Jul '15

#8353: Easy way to defer type errors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A number of comments I've heard recently have focused on the joy of `-fdefer-type-errors`, especially for newcomers to Haskell. However, in GHCi, one has to 1. be aware that `-fdefer-type-errors` exists 2. know the `:set ...` syntax to turn it on, and then 3. is stuck with this setting on until they turn it off Instead, I propose new `:load!` and `:reload!` commands (abbreviated to `:l!` and `:r!`) which turn on `-fdefer-type-errors` just for that one command. When a load or reload fails, the error message could suggest these alternate forms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10