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

When parsing a nested comment, such as

{-
  {-  nested comment  -}
  {-# nested pragma  #-}
-}

The lexer returns the comment annotation as

{-
  {-  nested comment
  {-# nested pragma  #
-}

Restore the missing comment end markers in the annotation.

Reviewed By: austin

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

GHC Trac Issues: #10277

In RdrHsSyn.checkAPat the processing for ExprWithTySig is defined as

   ExprWithTySig e t _ -> do e <- checkLPat msg e
                             -- Pattern signatures are parsed as sigtypes,
                             -- but they aren't explicit forall points.  Hence
                             -- we have to remove the implicit forall here.
                             let t' = case t of
                                        L _ (HsForAllTy Implicit _ _
                                             (L _ []) ty) -> ty
                                        other -> other
                             return (SigPatIn e (mkHsWithBndrs t'))

The t' variable ends up losing its original SrcSpan in the first case
branch. This results in annotations becoming detached from the AST.

Reviewed By: austin

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

GHC Trac Issues: #10255

It's pretty irritating having hasktags with multiple top-level
declarations with the same type; hasktags can't figure out which
declaration you actually wanted.

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

Reviewed By: dterei, austin

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

Add "error:" prefix to error-messages, also lowercase "Warning:"
message to match GCC behavior closer.

Reviewed By: thomie, austin

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

GHC Trac Issues: #10021

Trac #10218 reports a subtle bug that turned out to be:

- CSE invalidated the usage information computed
  by earlier demand analysis, by increasing sharing

- that made a single-entry thunk into a multi-entry thunk

- and with -feager-blackholing, that led to <<loop>>

The patch fixes it by making the CSE pass zap usage information for
let-bound identifiers.   It can be restored by -flate-dmd-anal.

(But making -flate-dmd-anal the default needs some careful work;
see Trac #7782.)

The opt_sig production is defined as

  opt_sig :: { ([AddAnn],Maybe (LHsType RdrName)) }
          : {- empty -}                   { ([],Nothing) }
          | '::' sigtype                  { ([mj AnnDcolon $1],Just $2) }

It is used in the alt and decl_no_th productions, but neither of them
add the returned annotations.

This commit captures the annotations in the calling productions.

Reviewed By: austin

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

GHC Trac Issues: #10254

The `guardquals1` production includes

   : guardquals1 ',' qual  {% addAnnotation (gl $ last $ unLoc $1) AnnComma
                                             (gl $2) >>
                               return (sLL $1 $> ($3 : unLoc $1)) }

The AnnComma should be attached to `(gl $ head $ unLoc $1)`, rather than
`last`.

Reviewed By: austin

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

GHC Trac Issues: #10256

The production for opt_kind_sig is

  opt_kind_sig :: { Located (Maybe (LHsKind RdrName)) }
          :                             { noLoc Nothing }
          | '::' kind                   {% ajl (sLL $1 $> (Just $2)) AnnDcolon (gl $1) }

The outer Location is used only to get the full span for the enclosing
declration, and is then stripped. The inner LHsKind then has a SrcSpan that does
not include the '::'

Extend the SrcSpan on $2 to include $1

Reviewed By: austin

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

GHC Trac Issues: #10209

Reviewed By: edsko, austin

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

GHC Trac Issues: #10232

Reviewed By: austin

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

Reviewed By: austin

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

GHC build system have custom autoconf check for `create_timer()`
function from librt. Check description says that it checks for
`CLOCK_REALTIME` timer, but checking code also checks for
`CLOCK_PROCESS_CPUTIME_ID` timer, which is not commonly present (for
example, FreeBSD doesn't have it). This makes whole check fail despite
the fact that FreeBSD have `create_timer()` call and supports
`CLOCK_REALTIME`. As a consequence, GHC RTS falls back to using SIGALRM
for its timing machinery. Not only it's very ancient codepath, it also
break some FFI bindings to C code that isn't prepared for syscall
interruption caused by SIGALRM delivery.

Grepping through ghc source code reveals that `USE_TIMER_CREATE`
defininition in the config.h doesn't imply having
`CLOCK_PROCESS_CPUTIME_ID`. The only place where
`CLOCK_PROCESS_CPUTIME_ID` is used is rts/posix/GetTime.c and this code
handles the absence of `CLOCK_PROCESS_CPUTIME_ID` gracefully.

This patch makes autoconf checking code to check only for
`timer_create(CLOCK_REALTIME, ...)` and fixes check description.

Reviewed By: austin

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

* distrib/configure.ac.in : Detect correct version of LLVM tools as
  was done for the top level configure.ac in 42448e37.
* aclocal.m4 : Add a FIND_LD macro that can be used in both
  configure scripts.
* Use new FIND_LD macro in both configure scripts.

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

Test Plan: validate on amd64-linux and armhf-linux.

Reviewers: rwbarton, austin

Subscribers: thomie

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

GHC Trac Issues: #10234

Note [Bind new Givens immediately] in TcRnTypes

We were never using the generality.  Result: less code, more efficient.
Cake for everyone.