Fix #10263.

by eta-expanding its definition so that GHC optmizes the foldl here.
Also make sure that other uses of last go via foldl as well, to allow
list fusion (tested in T9339). Fixes #10260.

(Next time, when fixing someone else’s mistake, I really shouldn’t do
the precise same thing.)

In response to suggestions on Trac #10281

Don't suggest -XImpredicativeTypes; and document its flakiness
Fixes Trac #10325

More fallout from the silent-superclass refactoring; nothing drastic.
Fixes Trac #10335.

Summary:
hs-boot declarations were leaking into the EPS due to
self {-# SOURCE #-} imports, and interface loading induced by
orphan instances.  For the former, we simply disallow self
{-# SOURCE #-} imports; for the latter, we simply just don't
load an interface if it would be ourself.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D860

GHC Trac Issues: #10182

Summary:
It's kind of buggy, c.f. #10182, and isn't motivated by any
real world programs, so we're going to get rid of it (despite
it being handy for GHC test cases.)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D862

as Simons recent commit 9b9fc4c7 fixed
this.

We really don't want to unify (a b) with (Eq a => ty).
The ever-ingenious Oerjan discovered this problem;
see comment:101 in Trac #9858.

See Note [Decomposing fat arrow c=>t] in Type.hs

In TcRnDriver.checkHiBootIface' we were generating an
impedence-matching binding
   $fxToRecMaybe = $fToRecMaybe
but the type of the former was gotten from the *hi-boot*
file, so its type constructor was not fully fleshed out.
That should never happen.

Fix is easy, happily.  A dark corner.

Like 32 bit Arm, Aarch64 requires use of the gold linker.

Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

Test Plan: 'make install' on aarch64, validate elsewhere

Reviewers: rwbarton, bgamari, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D858

GHC Trac Issues: #9673

Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

Test Plan: Full build on Aarch64

Reviewers: rwbarton, bgamari, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D859

Accompanies f2d1b7fc
Support unboxing for GADT product types

This fixes a typo in d5773a49
    Teach DmdAnal that coercions are value arguments!
    (Trac #10288)

Sorry about that; I'm not sure how it slipped through.

Beofre this commit we never unboxed GADT, even if they
are perfectly civilised products.

This patch liberalises unboxing slightly.
See Note [Product types] in TyCon.

Still to come
 - for strictness, we could maybe deal with existentials too
 - todo: unboxing constructor arguments

Coercion variables are used in casts and coercions, so the demand
analyser should jolly well not regard them as absent!

In fact this bug never makes a difference because even absent
unboxed-coercion arguments are passed anyway;
see WwLib.mk_abesnt_let, which returns Nothing for coercion Ids.

But it was simply wrong before and that is never cool.

The demand analyser was treating coercion args like type args,
which meant that the arguments in a strictness signature got
out of step with the arguments of a call.  Result chaos and
disaster.  Trac #10288 showed it up.

It's hard to get this bug to show up in practice because
 - functions abstracted over coercions are usually abstracted
   over *boxed* coercions
 - we don't currently unbox a boxed-coercion arg because it's
   GADT (I see how to fix this too)

But after floating, optimisation, and so on, Trac #10288 did
get a function abstracted over an unboxed coercion, and then
the -flate-dmd-anal pass went wrong.

I don't think I can come up with a test case, but I don't think
it matters too much.

Still to come
 - Fix a second bug, namely that coercion variables are wrongly
   marked as absent because DmdAnal doesn't check the the free
   variables of casts. I think this never bites in practice
   (see the follow-up commit)

 - Make GADT products work with strictness analysis

Highlights since 1.22.2.0:

- cabal check will fail on -fprof-auto passed as a ghc-option
- filterConfigureFlags: filter more flags.
- fix ghcjs-pkg version number handling

Addresses #10304

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Summary:
When we use -dppr-debug, we'll sometimes attempt to
hit the pkgState to give more detailed information.  It's pretty
annoying to have this fail because we haven't filled in the
pkgState: we can still get useful debugging information by
printing the raw package key.  To avoid this, we just put
in some empty stub pkgState, to be filled in later.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D817

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: comments only

Reviewers: simonpj, austin, goldfire

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D820

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: comments only

Reviewers: simonpj, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D816

Javran Cheng authored 9 years ago and Erik de Castro Lopo committed 9 years ago

This patch provides user with a better hint when most RTS options
are not available (not compiled with `-rtsopts`).

A new field "rtsOptsEnabled" is added into RtsFlags.MiscFlags to
tell the availablity of RTS options.

Some concerns:
* Unlike other flag fields in "libraries/base/GHC/RTS/Flags.hsc",
  "RtsOptsEnabled" is defined in "includes/RtsAPI.h" and lacks
  constant macros. Therefore In "GHC.RTS", "RtsOptsEnabled" simply
  derives Enum instance and reads as of type "CInt".

* There are other ways to change RTS options (e.g. `-with-rtsopts`),
  but it might be too verbose to mention.

Test Plan: validate

Reviewers: austin, hvr, thomie, simonmar

Reviewed By: thomie

Subscribers: thomie, rwbarton

Differential Revision: https://phabricator.haskell.org/D767

GHC Trac Issues: #9579

The changes are:
  1. No impredicative types in `Typeable`
  2. Distinguish normal tuples, from tuples of constraints.

The situation is similar to `Typeable`---we can't set the evidence
outside the solver because we have custom solving rules.  This is safe
because the computed super-class instances can't possibly depend
on the new instance.

Sometimes (especial with derived Data instances, it seems), one can have
very large mutually recursive bindings. Calculating the Call Arity
analysis result with full precision is an expensive operation in these
case. So above a certain threshold (25, for no good reason besides
intuition), skip this calculation and assume the recursion is not
linear, which is a conservative result.

With this, the Call Arity analysis accounts for 3.7% of the compile time
of haskell-src-exts. Fixes #10293

Differential Revision: https://phabricator.haskell.org/D843

This improves how the Call Arity deals with "boring" variables. Boring
variables are those where it does not bother to include in the analysis
result, so whenever something is looked up in the analysis result, we
have to make a conservative assumption about them.

Previously, we extended the result with such conservative information
about them, to keep the code uniform, but that could blow up the amount
of data passed around, even if only temporarily, and slowed things down.

We now pass around an explicit list (well, set) of variable that are
boring and take that into account whenever we use the result. Not as
pretty, but noticably faster.

See Note [Closing over kinds in coverage] in FunDeps.
I'd already fixed this bug once, for Trac #8391, but I put the
call to closeOverKinds in the wrong place, so Trac #10109
failed.  (It checks the /liberal/ coverage condition, which

The fix was easy: move the call to the right place!

The astonishingly-ingenious trio of
Shachaf Ben-Kiki, Ørjan Johansen and Nathan van Doorn
managed to persuade GHC 7.10.1 to cough up unsafeCoerce.

That is very bad. This patch fixes it by no allowing Typable
on Constraint-kinded things.  And that seems right, since
it is, in effect, a form of impredicative polymorphism,
which Typeable definitely doesn't support.

We may want to creep back in the direction of allowing
Typeable on constraints one day, but this is a good
fix for now, and closes a terrible hole.

There is currently no way to separate whether UnicodeSyntax is accepted
for input from the corresponding output syntax using unicode symbols.
This patch implements a separate flag for affecting ghc(i)'s output.

Signed-off-by: Bertram Felgenhauer <int-e@gmx.de>

Reviewed By: nomeata, austin

Differential Revision: https://phabricator.haskell.org/D807

GHC Trac Issues: #8959