GitLab

Proc-point splitting is only required by backends that do not support
having proc-points within a code block (that is, everything except the
native backend, i.e. LLVM and C).

Not doing proc-point splitting saves some compilation time, and might
produce slightly better code in some cases.

Keep the warning off for template-haskell and bytestring for the moment.

All the flags that 'ways' imply are now dynamic

Also, temporarely disable that warning for validate builds, until we
finish fixing them all.

I suspect I have done the wrong thing; I hope someone can improve.

The only difference between SevDump and SevOutput in defaultLogAction is
an extra blank line, so we don't need a separate hPrintDump function.

Also make -ddump-to-file consistent with the stdout version, by avoiding
to add the extra empty line when dumping rules.

Hopefully I've kept the logic the same, and we now generate warnings if
the user does -fno-PIC but we ignore them (e.g. because they're on OS X
amd64).

We now handle the preprocessor options the same way as the gcc options
(picCCOpts).

This patch re-implements implicit parameters via a class
with a functional dependency:

    class IP (n::Symbol) a | n -> a where
      ip :: a

This definition is in the library module GHC.IP. Notice
how it use a type-literal, so we can have constraints like
   IP "x" Int
Now all the functional dependency machinery works right to make
implicit parameters behave as they should.

Much special-case processing for implicit parameters can be removed
entirely. One particularly nice thing is not having a dedicated
"original-name cache" for implicit parameters (the nsNames field of
NameCache).  But many other cases disappear:

  * BasicTypes.IPName
  * IPTyCon constructor in Tycon.TyCon
  * CIPCan constructor  in TcRnTypes.Ct
  * IPPred constructor  in Types.PredTree

Implicit parameters remain special in a few ways:

 * Special syntax.  Eg the constraint (IP "x" Int) is parsed
   and printed as (?x::Int).  And we still have local bindings
   for implicit parameters, and occurrences thereof.

 * A implicit-parameter binding  (let ?x = True in e) amounts
   to a local instance declaration, which we have not had before.
   It just generates an implication contraint (easy), but when
   going under it we must purge any existing bindings for
   ?x in the inert set.  See Note [Shadowing of Implicit Parameters]
   in TcSimplify

 * TcMType.sizePred classifies implicit parameter constraints as size-0,
   as before the change

There are accompanying patches to libraries 'base' and 'haddock'

All the work was done by Iavor Diatchki

In particular, fields like 'flags' are now set to the default,
so at least they will work to some extent.

Summary:
  - mdo expressions are enabled by RecursiveDo pragma

  - mdo expressions perform full segmentation

  - 'rec' groups inside 'do' are changed so they do *not*
    perform any segmentation.

  - Both 'mdo' and 'rec' are enabled by 'RecursiveDo'
    'DoRec' is deprecated in favour of 'RecursiveDo'
    (The 'rec' keyword is also enabled by 'Arrows', as now.)

Thanks to Levent for doing all the work

A side-effect is that we can no longer use the LogAction in
defaultErrorHandler, as we don't have DynFlags at that point.
But all that defaultErrorHandler did is to print Strings as
SevFatal, so now it takes a 'FatalMessager' instead.

We now use log_action with severity SevDump, rather than calling
printDump. This means that what happens to dumped info is now under
the control of the GHC API user, rather than always going to stdout.

We now use this function rather than Outputable.{printSDoc,printErrs}.

Outputable is arguably a better home for the function, but putting it
in DynFlags should dissuade people from using it inappropriately (in
particular, nothing other than the default hooks should have stdout
or stderr hardcoded).

Not exporting it at all would also be an option, but exporting it with
an ungainly name will make it slightly easier for people who want to
send output to other Handles for some reason.

Previously, the `-no-user-package` and `-no-global-package` flags
affected the "initial" stack only, while `user-package` and
`global-packages` appended to the end of the stack.

This commit changes the behavior of those flags, so that they are always
applied to the stack as a whole.

The effect of the GHC_PACKAGE_PATH environment variable has also been
changed: terminating it with a separator now adds the default package
dbs (user and global) instead of the initial stack.

Rename package database flags in both GHC and ghc-pkg so that they are
consistent with Cabal nomenclature.

Add a version check to the build system so that the correct set of
package db flags are used when the bootstrapping GHC has version < 7.5.