- ghc-tickets - Haskell.org

[GHC] #13437: Easier editing of multi-line GHCi-commands
by GHC 17 Mar '17

17 Mar '17

#13437: Easier editing of multi-line GHCi-commands -------------------------------------+------------------------------------- Reporter: fredefox | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- In my terminal emulator I can write something like: {{{ cat > /dev/null << EOF bla bla bla EOF }}} If I later want to edit something in this command I can recall the command from history and I can navigate to the line I want to change. In GHCi this is not possible, the history only recalls *one line* at a time. It would be nice if it recognized commands entered using {{{ :{ ... }: }}} and would give you that whole command when recalling commands from the history. Also, it would be very handy if doing e.g. Shift+Enter would insert a newline into your multi-line command rather than run the command. Furthermore, it could also serve as a handy shortcut for engaging the multi-line command mode. So say you were sitting at the prompt {{{ > }}} and you then hit enter, then GHCi moves to a new-line but has inserted the {{{ :{ }}} part for you, it could similarly close the command for you when you hit Enter (without holding down the modifier key). I believe this change would make GHCi's multi-line command mode way more useful. Currently I very seldomly (if ever) use GHCi for anything other than one-liners. This means that I usually have to edit the source-file I'm currently working on to put things into scope (or try and formulate a long and awkward expression). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#
by GHC 17 Mar '17

17 Mar '17

#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D3358 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => phab:D3358 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4092#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13436: feature for checking files in temp location
by GHC 17 Mar '17

17 Mar '17

#13436: feature for checking files in temp location -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- ghc-pkg register can do sanity checks on files being in the right place. These are a useful sanity check. The checks can also be disabled with the `--force-files` flag. When installing package files and registering we can either install files and then register or the reverse. The reverse style can be helpful in simplifying the locking system that allows concurrent package installation and use. In particular, new versions of cabal will 1. prepare all package files in a temporary directory; 2. register with ghc-pkg; and 3. use an atomic directory rename to move the package files to their final location This procedure simplifies the locking considerably by not requiring any locks between concurrent package readers and writers, just requiring locks between concurrent writers. Step 2 above requires that we be able to register when the files are not yet in their final location. This can be done with the `--force-files` flag, but we lose out on the useful sanity checks. So this feature request is for a flag that lets us say "do please do the file checks, but instead of looking for files in their final locations, look for them here". Since file paths in the package registration info are usually absolute paths, then the specification of where to look for files would need to be done in terms of changing a prefix. For example, a registration file may contain: {{{ import-dirs: /home/me/.cabal/store/uniplate-1.6.12-3K1HlYoxKOQ3XlQlOoSFWj }}} And this is used to check for the .hi files for all the modules. But in the above scenario the files will actually all be in /home/me/.cabal/store/**incoming**/uniplate-1.6.12-3K1HlYoxKOQ3XlQlOoSFWj so we will want to say something like: {{{ ghc-pkg register uniplate.conf \ --file-root=/home/me/.cabal/store/=/home/me/.cabal/store/incoming/ }}} or another example of a slightly different use case would be {{{ ghc-pkg register uniplate.conf \ --file-root=/=$PWD/image/ }}} this is for the case of `--prefix=/usr/local` and `make install DESTDIR=$PWD/image` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13432: ghc: panic! (the 'impossible' happened)
by GHC 17 Mar '17

17 Mar '17

#13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **Command** {{{ ghc -c prettystub.hs }}} **Result** {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] hexEscape_a2yj :: t_a2yi[tau:1] (CHoleCan: hexEscape)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12718: Segmentation fault, runtime representation polymorphism
by GHC 16 Mar '17

16 Mar '17

#12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- 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: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RebindableSyntax, NoImplicitPrelude, MagicHash, RankNTypes, PolyKinds, ViewPatterns, TypeInType, FlexibleInstances #-} import Prelude hiding (Eq (..), Num(..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: TYPE rep) where (+) :: a -> a -> a fromInteger :: Integer -> a instance P.Num a => Num a where (+) = (P.+) fromInteger = P.fromInteger instance Num Int# where (+) = (+#); fromInteger (fromInteger -> I# n) = n u :: Bool u = isTrue# v_ where v_ :: forall rep (a :: TYPE rep). Num a => a v_ = fromInteger 10 }}} segfaults {{{#!hs $ ./bin/repo/ghc4/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/tMjN.hs GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tMjN.hs, interpreted ) Ok, modules loaded: Main. *Main> u True *Main> Segmentation fault (core dumped) $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls
by GHC 16 Mar '17

16 Mar '17

#11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: 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: -------------------------------------+------------------------------------- Consider the following use of `error`. {{{ ghci> :t error error :: forall (v :: GHC.Types.Levity) (a :: TYPE v). (?callStack::GHC.Stack.Types.CallStack) => [Char] -> a ghci> :t error "bad" :: (forall a. a -> a) -> a error "bad" :: (forall a. a -> a) -> a :: (?callStack::GHC.Stack.Types.CallStack) => (forall a1. a1 -> a1) -> a }}} GHC is instantiating the type variable `a` in the output with `(forall a. a -> a) -> a`, which requires impredicative polymorphism. So this example should actually be rejected by the type checker. Note that GHC also does this with open-kinded type variables, so the behavior with `error` and `undefined` has been around for a while. There are tests that depend on it, and a Note that describes the decision to accept these programs. Still, Simon PJ says perhaps we should really just reject these programs. So here's a ticket to discuss the matter. For more information, see the discussion starting at https://phabricator.haskell.org/D1739#51408. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case
by GHC 16 Mar '17

16 Mar '17

#13400: realgcc.exe do not run GHCi in Windows in a particular case ------------------------------+---------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+---------------------------- First, I start GHCi with a memory card insert in the slot of the computer. GHCi run ok. Second, I stop running GHCi and I remove the memory card. Third, I restart GHCi and a message appears in a window "realgcc.exe there is no disk - insert a disk in drive D:". When I reinsert the memory card, GHCi run again. Realgcc.exe is in the directory c:ghc-8.0.2\mingw\bin. Hope this help! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13388: Caret diagnostics interact badly with hsc2hs
by GHC 16 Mar '17

16 Mar '17

#13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I saw this recently, {{{ libraries\Win32\Graphics\Win32\Window.hsc:188:46: error: Not in scope: type constructor or class `Int32' | 188 | cW_USEDEFAULT = fromIntegral (#{const CW_USEDEFAULT} :: Int32) | ^^^^^ }}} Clearly the caret is pointing to the wrong place in the line. Note that the file in question is a `hsc2hs` file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13401: GHCi gives conflicting information about visible type application
by GHC 15 Mar '17

15 Mar '17

#13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- From the docs for `-XVisibleTypeApplication`: >When printing types with `-fprint-explicit-foralls` (page 72) enabled, type variables not available for visible type application are printed in braces. Thus, if you write `myLength = length` without a type signature, `myLength`‘s inferred type will be `forall {f} {a}. Foldable f => f a -> Int`. {{{ > :set -XScopedTypeVariables > :set -XTypeApplications > :set -fprint-explicit-foralls > let foo :: forall a. a; foo = undefined (LINE 1) > :t foo foo :: forall {a}. a (LINE 2) > > :t (foo @Bool) (foo @Bool) :: Bool (LINE 3) }}} Type application with `foo` (LINE 1) should be possible, but GHCi claims it is not (LINE 2), then allows it anyway (LINE 3). This looks like a bug with `fprint-explicit-foralls` in detecting which variables are available for type application. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13401> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13428: internal error: Can't allocate thunk for free
by GHC 15 Mar '17

15 Mar '17

#13428: internal error: Can't allocate thunk for free -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: RTS linker | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to compile `stack` with `ghc-8.0.2` resulted in this: {{{ [ 73 of 124] Compiling Stack.PackageIndex ( src\Stack\PackageIndex.hs, C:\Users\abiehl\git\stack\dist- newstyle\build\x86_64-windows\ghc-8.0.2\stack-1.4.1\build\Stack\PackageIndex.o ) ghc.exe: internal error: Can't allocate thunk for free (GHC version 8.0.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. cabal.exe: Failed to build stack-1.4.1. The build process terminated with exit code 3 }}} The file in question uses `TemplateHaskell` and I suspect the runtime linker to be the culprit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2