March 2015 - ghc-tickets

[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 04 Jul '15

04 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

[GHC] #9723: Give Tab warning only once per file
by GHC 04 Jul '15

04 Jul '15

#9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Currently, when compiling a tabbed file, GHC spits out a huge number of warnings: {{{ Main.hs:1:1: Warning: Tab character [..] Main.hs:89:1: Warning: Tab character Main.hs:90:1: Warning: Tab character Main.hs:91:1: Warning: Tab character Main.hs:92:1: Warning: Tab character Main.hs:99:4: Warning: Tab character Main.hs:100:4: Warning: Tab character Main.hs:101:4: Warning: Tab character }}} This is annoying and not very nice to our users. I suggest to replace it by {{{ This file contains tabs (e.g. line n column m); please use spaces instead }}} or (to be nice to tools that parse this output) {{{ Main.hs:1:1: Tab found here, and in n further locations. Please use spaces instead. }}} (This is clearly a low priority request, but also possibly some low- hanging fruit for new contributors.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8881: No way to unsubscribe a bug
by GHC 04 Jul '15

04 Jul '15

#8881: No way to unsubscribe a bug ------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current trac settings are so that when I comment on a bug, I am automatically subscribed to it. This is good, but there should be way to unsubscribe from a bug as well. Also, and I’m not sure if this is the same thing or not, if I put myself in the “Observer” list (possibly wrong translation), I cannot undo that. Generally, we might give our users more permissions, e.g. to edit ticket descriptions (and not just the summary). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with
by GHC 03 Jul '15

03 Jul '15

#8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- make -j3 fails with Configuring ghc-bin-7.7.20131217... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestar… for details. Stop. make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9675: Unreasonable memory usage on large data structures
by GHC 03 Jul '15

03 Jul '15

#9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have attached a file that, when compiled, results in very large amount of memory usage by GHC. The memory used is in the order of tens of gigabytes, but I've not been able to successfully compile the file due to lack of physical memory. This is on Debian GNU/Linux (Jessie) using Haskell Platform 2014.2.0.0 with GHC 7.8.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10006: Add baseline ellipsis as unicode alternative to «..»
by GHC 03 Jul '15

03 Jul '15

#10006: Add baseline ellipsis as unicode alternative to «..» -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While the current unicode syntax is overall very pleasing to the eye, writing the ellipsis as two periods («..») sticks out quite noticably. I would welcome it if the horizontal ellipsis (U+2026, «…») would be allowed in places where «..» can be written. I noticed that there was an old discussion on the mailing list which indicated that originally there was a unicode replacement for «..», namely the midline ellipsis, which wasn’t considered a good choice and was removed from the syntax. The regular ellipsis would have the advantage that it is one of the more common «fancy» characters and mapped by default in the X server compose definitions; as such it’s rather well-accepted and sees use even on IRC and in blogs. So user’s would potentially benefit from the regular ellipsis, much more so than the more exotic midline ellipsis. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9119: Additional symbols for XUnicodeSyntax
by GHC 03 Jul '15

03 Jul '15

#9119: Additional symbols for XUnicodeSyntax -------------------------------------------+------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.2 Keywords: unicode | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- So, one of the things I love about Haskell is how relatively mathematically friendly it is. To that end, I propose the following additional unicode operators be added to XUnicodeSyntax: "⊦ p → x" for "let p in x" "≝" "≜" "≛" "≚" "≙" "≟" "⇔" "≐" "≞" be added as synonyms for "=" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9977: Nicer imports
by GHC 03 Jul '15

03 Jul '15

#9977: Nicer imports -------------------------------------+------------------------------------- Reporter: tolysz | Owner: Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: imports | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hi, I wonder if we could have {{{#!hs import Data A B (ba, bb, bc) C as C C1 as C1 (ca,cb,cc) D qualified E as E qualified F as F qualified (fa, fb, fc) Libs.Other -- Data.E qualified as E -- both valid -- Data.F qualified as F (fa, fb, fc) }}} to desugar to {{{#!hs import Data.A import Data.B (ba, bb, bc) import Data.C as C import qualified Data.D import qualified Data.E as E import qualified Data.F as F (fa, fb, fc) import Libs.Other }}} so we could make syntax more dry? What it does if there is indentation it uses previous levels as prefix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8363: Order matters for unused import warnings when reexporting identifiers
by GHC 01 Jul '15

01 Jul '15

#8363: Order matters for unused import warnings when reexporting identifiers ------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | 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: | ------------------------------------+------------------------------------- Import order seem to change whether unused import warnings trigger when a module re-exports an identifier, with another module importing it and another module exporting the same identifier. Reproduction: {{{ module Foo ( (<$>) , g ) where import Control.Applicative g :: Int g = 1 }}} {{{ module Main where import Control.Applicative import Foo main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ $ ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} If Main is not using `g` then this gives a warning that the import of `Foo` is redundant. If we switch the order of the imports we do get the warning: {{{ module Main where import Foo import Control.Applicative main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ > ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:4:1: Warning: The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() Linking Main ... }}} I expected both versions of Main to produce the same warning. Tested on GHC 7.7.20130824 and 7.4.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4