GitLab

We used to say 10.3, but this gives
    -rpath can only be used when targeting Mac OS X 10.5 or later 
when building shared libraries.
Patch from mwotton.

 - remove the main: stuff
 - show the filenames
 - don't clutter the output with imports that aren't involved in
   the cycle

So that Cabal, if it wants, can use a more general algorithm to find a
consistent set of packages to use.

- We have -m32 as machine-dependent option for gcc for a 32 bit build
- Like on OpenBSD, SL requires -fno-stack-protector to avoid triggering the
  stack smashing checks inserted by gcc by default on this platform.

For type checker warnings, the context information ("In the expression
...") was simply appended to the main message while for proper errors
they live in errMsgExtraInfo.  This allows GHC API clients to drop
that information if not needed.

Performance isn't an issue for reading the old-style package.conf
files, so we might as well revert to using read and fix a bug at the
same time.

 - the package DB is a directory containing one file per package
   instance (#723)

 - there is a binary cache of the database (#593, #2089)

 - the binary package is now a boot package

 - there is a new package, bin-package-db, containing the Binary
   instance of InstalledPackageInfo for the binary cache.

Also included in this patch

 - Use colour in 'ghc-pkg list' to indicate broken or hidden packages
  
   Broken packages are red, hidden packages are 
  
   Colour support comes from the terminfo package, and is only used when
    - not --simple-output
    - stdout is a TTY
    - the terminal type has colour capability

 - Fix the bug that 'ghc-pkg list --user' shows everything as broken

A few changes bundled together here:

 - Add -package-id flag, like -package but takes an
   InstalledPackageId as an argument (mainly for Cabal)
   (docs to follow)

 - Fix the shadowing behaviour: if we end up with
   two packages with the same name/version that came from
   different package databases, then one will shadow the
   other.  This may mean we have to disable other packages
   that depended on the now-shadowed package.  Lots of
   refactoring to ensure that we can get reasonable diagnostics when
   this happens

<command line>: cannot satisfy -package shadowdep: 
    shadowdep-1-XXX is unusable due to missing or recursive dependencies:
      shadow-1-XXX
    (use -v for more information)

  - tracing facilities are now enabled with -DTRACING, and -DDEBUG
    additionally enables debug-tracing.  -DEVENTLOG has been
    removed.

  - -debug now implies -eventlog

  - events can be printed to stderr instead of being sent to the
    binary .eventlog file by adding +RTS -v (which is implied by the
    +RTS -Dx options).

  - -Dx debug messages can be sent to the binary .eventlog file
    by adding +RTS -l.  This should help debugging by reducing
    the impact of debug tracing on execution time.

  - Various debug messages that duplicated the information in events
    have been removed.

See commentary at
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Packages

Also, -fPIC causes an error if the target is registerised and has no
native code generator.

* Make C { A.a } work with punning, expanding to C { A.a = a }

* Make it so that, with -fwarn-unused-matches, 
        f (C {..}) = x
  does not complain about the bindings introduced by the "..".

* Make -XRecordWildCards implies -XDisambiguateRecordFields.

* Overall refactoring of RnPat, which had become very crufty. 
  In particular, there is now a monad, CpsRn, private to RnPat,
  which deals with the cps-style plumbing.  This is why so many
  lines of RnPat have changed.

* Refactor the treatment of renaming of record fields into two passes
	- rnHsRecFields1, used both for patterns and expressions,
	     which expands puns, wild-cards
  	- a local renamer in RnPat for fields in patterns
	- a local renamer in RnExpr for fields in construction and update
  This make it all MUCH easier to understand
 
* Improve documentation of record puns, wildcards, and disambiguation

Also, I cleaned up some of the way-related infrastructure, removing
two global variables.  

There's more that could be done here, but it's a start.  The way flags
probably don't need to be static any more.

Turns out using atomic update instead of a full-blown lock was easier
than I thought.  It should also be safe in the case where we
concurrently read the same interface file.  Whichever thread loses the
race will simply find that all of the names are already defined and
will have no effect on the name cache.

'readBinIface' updates the name cache in a way that is hard to use
with atomicModifyIORef, so this patch introduces a lock for this case.
All other updates use atomicModifyIORef.

Having a single lock is quite pessimistic, so it remains to be seen
whether this will become a problem.  In principle we only need to make
sure that we do not load the same file concurrently (or that it's
idempotent).  In practice we also need to ensure that concurrent reads
do not cancel each other out (since the new NameCache may be based on
an outdated version).

Flushing and uncaching a single module is not completely atomic since
both caches a cleared separately.  However, flushing is only done when
changing the working directory which shouldn't be done concurrently to
other threads.  Uncaching is only done in 'summariseModule' which
requires some more work to become thread-safe anyway.

The first phase of this tidyup is focussed on the header files, and in
particular making sure we are exposinng publicly exactly what we need
to, and no more.

 - Rts.h now includes everything that the RTS exposes publicly,
   rather than a random subset of it.

 - Most of the public header files have moved into subdirectories, and
   many of them have been renamed.  But clients should not need to
   include any of the other headers directly, just #include the main
   public headers: Rts.h, HsFFI.h, RtsAPI.h.

 - All the headers needed for via-C compilation have moved into the
   stg subdirectory, which is self-contained.  Most of the headers for
   the rest of the RTS APIs have moved into the rts subdirectory.

 - I left MachDeps.h where it is, because it is so widely used in
   Haskell code.
 
 - I left a deprecated stub for RtsFlags.h in place.  The flag
   structures are now exposed by Rts.h.

 - Various internal APIs are no longer exposed by public header files.

 - Various bits of dead code and declarations have been removed

 - More gcc warnings are turned on, and the RTS code is more
   warning-clean.

 - More source files #include "PosixSource.h", and hence only use
   standard POSIX (1003.1c-1995) interfaces.

There is a lot more tidying up still to do, this is just the first
pass.  I also intend to standardise the names for external RTS APIs
(e.g use the rts_ prefix consistently), and declare the internal APIs
as hidden for shared libraries.

We were keeping things as Int, and then converting them to Word16 at
the last minute, when really they ought to have been Word16 all along.

Instead of chr_$wchr, we now just get $wchr.  In general, when an
OccName is system-generated, we leave it out of the final external
name, preferring to use the name of the exported parent instead (which
is necessarily a user-written name).

Names should be no less deterministic, but should be shorter and more
readable.

Fixes #3168

This means GHC knows whether it's building a Cabal package, or just
Haskell sources. For example, it may wish to give different error
messages when building a Cabal package.

This patch adds tuple sections, so that

	(x,,z)  means   \y -> (x,y,z)

Thanks for Max Bolinbroke for doing the hard work.

In the end, instead of using two constructors in HsSyn, I used
just one (still called ExplicitTuple) whose arguments can be
	Present (LHsExpr id)
or	Missing PostTcType

While I was at it, I did a bit of refactoring too.

Now, for a compiler-generated binding "x", if "x" is referred to by
the exported "f", then it will be named "f_x" rather than something
like "x23".  This means that hopefully

  - compilation will more often product the same results given the
    same input (the choice of names is not dependent on the
    non-deterministic order of bindings within the compiler).

  - less recompilation will be necessary after making changes

  - navigating Core might be a bit easier.

unfortunately, compilation with -O still does not consistently produce
the same ABI.  The simplifier sometimes does different things,
apparently.

Names will be longer, but I can't see a way around that.

This is used to control warnings that were previously unconditional.