#13027: Core lint errors compiling containers HEAD with GHC HEAD
-------------------------------------+-------------------------------------
Reporter: erikd | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 8.2.1
Component: Compiler | Version: 8.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Building GHC
Unknown/Multiple | failed
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Git HEAD of containers compiles fine with ghc-8.0.1, but when compiling
with
GHC git HEAD gives core lint errors:
{{{
*** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = False})
***
<no location info>: warning:
In the expression: tagToEnum#
@ Bool (reallyUnsafePtrEquality# @ (Set a)
l'_a4Fk l_a4Fi)
This argument does not satisfy the let/app invariant:
reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi
*** Offending Program ***
Rec {
$dTypeable_s9vn :: Proxy# Set -> TypeRep
}}}
This issue can be reproduced using:
{{{
(cd libraries/containers ; git checkout master ; git pull)
perl boot && ./configure && make clean && make -j
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13027>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13369: Float-out is not idempotent
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: (none)
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:
-------------------------------------+-------------------------------------
Consider
{{{
f x = BIG
}}}
where BIG is bottoming. In HEAD, the float-out pass decides to float BIG
to the top level, producing
{{{
lvl x = BIG
f x = lvl x
}}}
which is obviously stupid.
There's a whole Note to explain this problem and how we avoid it:
{{{
Note [Floating from a RHS]
~~~~~~~~~~~~~~~~~~~~~~~~~~
When float the RHS of a let-binding, we don't always want to apply
lvlMFE to the body of a lambda, as we usually do, because the entire
binding body is already going to the right place (dest_lvl).
A particular example is the top level. Consider
concat = /\ a -> foldr ..a.. (++) []
We don't want to float the body of the lambda to get
lvl = /\ a -> foldr ..a.. (++) []
concat = /\ a -> lvl a
That would be stupid.
}}}
But I forgot to take account of the possibility that `abs_vars` might
abstract over Ids. Easily fixed.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13369>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13329: Windows CMD.EXE "Quick Edit Mode"
-------------------------------------+-------------------------------------
Reporter: irongremlin | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: clipboard, | Operating System: Windows
quick edit |
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Behavior:
When a compiled haskell executable launches into a windows 7 'cmd.exe'
terminal session, it does not respect the users 'quick edit mode' setting,
and launches with the system default setting instead.
I have not replicated this issue on other versions of windows.
Details:
For a description of the feature behavior, see:
https://blogs.msdn.microsoft.com/adioltean/2004/12/27/useful-copypaste-
trick-in-cmd-exe/
The registry key entry controlling this setting is:
HKEY_CURRENT_USER\Console\QuickEdit (1 == on, 0 ==off)
Tiny illustrative program:
main :: IO ()
putStrLn "Try to copy this text" >>=(\_ -> getLine) >>= putStrLn
Additional notes:
The workaround is pretty simple, launch the program from a .bat script -
cmd /K myscript.exe
Or from inside an existing cmd.exe session, and the problem goes away.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13329>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13377: Compiler error: Simplifier ticks exhausted
-------------------------------------+-------------------------------------
Reporter: | Owner: (none)
simplifierticks |
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
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:
-------------------------------------+-------------------------------------
2.4 Programming jointly with types and values
Exercise 2.4.1 (Fixpoint). The lambda term:
y = = \f->(\x->f (x x)) (\x->f (x x))
(that encodes a fixed point combinator in the untyped lambda calculus)
does not type check in Haskell. Try it! Interestingly though, recursion on
the type level can be used to introduce recursion on the value level. If
we define the recursive type:
data F a = = F { unF :: F a->a }
then we can “annotate” the definition of y with applications of F and unF
such that y typechecks. Do it!
This works on someones else his computer:
{{{#!hs
data F a = F { unF :: F a -> a }
-- y = \f -> (\x -> f (x x)) (\x -> f (x x))
y = \f -> (\x -> x $ F x) (\x -> f . unF x $ x)
}}}
Compiler error:
ghc.EXE: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-mingw32):
Simplifier ticks exhausted
When trying UnfoldingDone x_s1Gq
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 6480
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Increased -fsimpl-tick-factor to 100.000 still the error occurred
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13377>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
