#12539: Possible typo causes Stack and Cabal installs to fail
-------------------------------------+-------------------------------------
Reporter: ConorIA | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Linux
Architecture: | Type of failure: Compile-time
Unknown/Multiple | crash
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or
to add pandoc to https://github.com/mitchty/alpine-ghc.
However, in both cases, install commands are running into an issue with
the '-nopie' flag passed to GCC.
The gist of the error thrown when using wither Cabal or Stack is:
{{{
<no location info>:
Warning: Couldn't figure out linker information!
Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc.
gcc: error: unrecognized command line option '-nopie'; did you mean '-no-
pie'?
)
}}}
I am not sure where the error is, as I am really a non-expert. But the gcc
linking option is "-no-pie", so if there is indeed an option "-nopie"
being passed, it seems like it is a typo.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12539>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7606: Stride scheduling for Haskell threads with priorities
-------------------------------------+-------------------------------------
Reporter: ezyang | Owner: ezyang
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 7.7
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by ezyang):
No new progress since my last comment! Perhaps we should resurrect this
patchset.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7606#comment:46>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#12804: forever contains a space leak
-------------------------------------+-------------------------------------
Reporter: tomjaguarpaw | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: | Version: 8.0.1
libraries/base |
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Runtime
Unknown/Multiple | performance bug
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
4.9.0.0's `forever` (implemented in terms of `Applicative`) has a space
leak for certain base `Monad`s. The old `forever` (implemented in terms
of `Monad`) does not.
See these messages for details
* https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125177.html
* https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125178.html
* https://mail.haskell.org/pipermail/haskell-
cafe/2016-November/125443.html
This is not necessarily `forever`'s fault. It seems likely that the
broken behaviour that occurs with `ReaderT` and `StateT` (on `IO`) could
be fixed by a specialised implementation of `*>` (for `ReaderT` and
`StateT`).
Perhaps, then, this bug should ultimately be fixed in `transformers` (and
various other packages which supply `Applicative`s) but it is a regression
introduced by base-4.9.0.0 so I think it's worthwhile to discuss here.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12804>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7606: Stride scheduling for Haskell threads with priorities
-------------------------------------+-------------------------------------
Reporter: ezyang | Owner: ezyang
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 7.7
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Changes (by simonmar):
* cc: simonmar (added)
Comment:
Edward, BTW what's the state of this? The last set of numbers look not
too bad at all.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7606#comment:45>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#12803: Functional dependencies and type families
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
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
{{{
type family F a :: *
class C a b | a -> b
instance C p (F q) => C p [q]
}}}
Is the instance decl OK under the liberal coverage condition?
That is, does `(C t [s1], C t [s2])` mean that `(s1 ~ s2)`?
NO! The context of the instance declaration means that `p -> F q` but
that does not imply `p -> q` unless `F` is injective!
So this program is wrongly accepted.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12803>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#12734: Unexpected context reduction stack overflow
-------------------------------------+-------------------------------------
Reporter: danilo2 | Owner:
Type: bug | Status: new
Priority: high | 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:
-------------------------------------+-------------------------------------
Hello!
I don't have a minimal example, but I've got a very clear strange
bahavior:
We've got a function:
{{{
nstar3 :: ( ExprCons t layers m, Bindable t m, Self.MonadSelfBuilder
(Binding (Expr2 t layers AnyLayout)) m
, ExprInferable t layers m)
=> m (Binding (PrimExpr2' t layers Star))
nstar3 = Self.put . anyLayout2 =<<& (nstar2 >>= mkBinding)
}}}
If I use it in a different function and use following explicit type, I get
the error:
{{{
test_gr3 :: ( ExprCons t layers m, Bindable t m, ExprInferable t layers m
, MonadIO m, Show bind, Show (PrimExpr2' t layers Star),
layers~'[Data, Type]
, Self.MonadSelfBuilder (Binding (Expr2 t layers AnyLayout)) m
, bind ~ Binding (PrimExpr2' t layers Star)
) => m bind
test_gr3 = do
sref <- nstar3
}}}
error (while using the function and evaluating monads):
{{{
• Reduction stack overflow; size = 201
When simplifying the following type:
MonadFix
(Self.SelfBuilderT (Binding (Expr2 t0 '[Data, Type] AnyLayout))
m)
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the second argument of ‘($)’, namely ‘(test_gr3)’
In the second argument of ‘($)’, namely
‘runInferenceT2 @TermType @Net $ (test_gr3)’
In the second argument of ‘($)’, namely
‘runInferenceT2 @InfLayers @'[Data, Type]
$ runInferenceT2 @TermType @Net $ (test_gr3)’
}}}
What is "funny" is that if I change the type of `test_gr3` to a very
similar one, I just replace the part `=> m bind` with manually expanded
one `m (Binding (PrimExpr2' t layers Star))` everything compiles fine.
It would be really hard to get minimal example out of it – it uses nested
mfixes and will take much time to cut it down. The question is – can we
locate the error based on the description?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12734>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#12787: Weird type constraint with undecidable instances
-------------------------------------+-------------------------------------
Reporter: nome | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
(Type checker) |
Keywords: | Operating System: Linux
UndecidableInstances |
Architecture: x86_64 | Type of failure: GHC rejects
(amd64) | valid program
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Minimal example:
{{{#!hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE UndecidableInstances #-}
module Test where
class PreOrd a where
(<~) :: a -> a -> Bool
class PreOrd a => PartialOrd a where
tryCompare :: a -> a -> Maybe Ordering
instance PartialOrd a => PreOrd a where
x <~ y = let cmp = tryCompare x y in cmp == Just LT || cmp == Just EQ
class PartialOrd a => TotalOrd a where
tcompare :: a -> a -> Ordering
instance TotalOrd a => PartialOrd a where
tryCompare x y = Just $ tcompare x y
instance TotalOrd Int where
tcompare x y = compare x y
}}}
GHC (tested with 7.10.3 and 8.0.1) rejects this with the following error:
{{{
test.hs:11:24: error:
• Could not deduce (TotalOrd a) arising from a use of ‘tryCompare’
from the context: PartialOrd a
bound by the instance declaration at test.hs:10:10-33
Possible fix:
add (TotalOrd a) to the context of the instance declaration
• In the expression: tryCompare x y
In an equation for ‘cmp’: cmp = tryCompare x y
In the expression:
let cmp = tryCompare x y in cmp == Just LT || cmp == Just EQ
}}}
After banging my head against this for a while, and having successfully
run this in Hugs, I tend to see it as a bug in GHC. Which is to say, I
have no idea why tryCompare could possibly require TotalOrd when it's
actually defined in its superclass.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12787>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#12584: Bug (or Unhelpful Error) with TemplateHaskell
-------------------------------------+-------------------------------------
Reporter: Shayan-Najd | 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:
-------------------------------------+-------------------------------------
To recreate this make a Haskell file say named 'T.hs', with the following
code:
{{{#!hs
{-# LANGUAGE TemplateHaskell #-}
(() -> ())
}}}
Then try to compile it:
{{{
$> ghc-stage2 T.hs
[...]
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20160617 for x86_64-unknown-linux):
tcMonoExpr _
[...]
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12584>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4162: GHC API messes up signal handlers
-------------------------------------+-------------------------------------
Reporter: jcpetruzza | Owner:
Type: bug | Status: patch
Priority: low | Milestone:
Component: GHC API | Version: 6.12.3
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:D2633
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Ben Gamari <ben@…>):
In [changeset:"8a5960ad874d31fcf631b4d427ccd9fae571745c/ghc"
8a5960ad/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="8a5960ad874d31fcf631b4d427ccd9fae571745c"
Uninstall signal handlers
GHC installs signal handlers in runGhc/runGhcT to handle ^C but it
never uninstalls them.
It can be an issue, especially when using GHC as a library.
Test Plan: validate
Reviewers: bgamari, erikd, austin, simonmar
Reviewed By: bgamari, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2633
GHC Trac Issues: #4162
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4162#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
