GitLab

I've put mkSOName in HscTypes for now; I'm not sure what the best place
for it is.

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.

This patch implements the idea of deferring (most) type errors to
runtime, instead emitting only a warning at compile time.  The
basic idea is very simple:

 * The on-the-fly unifier in TcUnify never fails; instead if it
   gets stuck it emits a constraint.

 * The constraint solver tries to solve the constraints (and is
   entirely unchanged, hooray).

 * The remaining, unsolved constraints (if any) are passed to
   TcErrors.reportUnsolved.  With -fdefer-type-errors, instead of
   emitting an error message, TcErrors emits a warning, AND emits
   a binding for the constraint witness, binding it
   to (error "the error message"), via the new form of evidence
   TcEvidence.EvDelayedError.  So, when the program is run,
   when (and only when) that witness is needed, the program will
   crash with the exact same error message that would have been
   given at compile time.

Simple really.  But, needless to say, the exercise forced me
into some major refactoring.

 * TcErrors is almost entirely rewritten

 * EvVarX and WantedEvVar have gone away entirely

 * ErrUtils is changed a bit:
     * New Severity field in ErrMsg
     * Renamed the type Message to MsgDoc (this change
       touches a lot of files trivially)

 * One minor change is that in the constraint solver we try
   NOT to combine insoluble constraints, like Int~Bool, else
   all such type errors get combined together and result in
   only one error message!

 * I moved some definitions from TcSMonad to TcRnTypes,
   where they seem to belong more

We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.

  This is work mostly done by Daniel Winograd-Cort during his
  internship at MSR Cambridge, with some further refactoring by me.

This commit adds support to GHCi for most top-level declarations that
can be used in Haskell source files.  Class, data, newtype, type,
instance are all supported, as are Type Family-related declarations.

The current set of declarations are shown by :show bindings.  As with
variable bindings, entities bound by newer declarations shadow earlier
ones.

Tests are in testsuite/tests/ghci/scripts/ghci039--ghci054.
Documentation to follow.

of the RTS addDLL() API on Windows.  When searching for DLLs we should
include the .dll extension, but addDLL() takes a filename without the
extension.

linking scenarios.  We weren't searching for .a archives to satisfy
-lfoo options on the GHCi command line, for example.

I've tidied up the code in this module so that dealing with -l options
on the command line is consistent with the handling of extra-libraries
for packages.

While I was here I moved some stuff out of Linker.hs that didn't seem
to belong here: dataConInfoPtrToName (now in new module DebuggerUtils)
and lessUnsafeCoerce (now in DynamicLoading, next to its only use)

When a plugin is loaded, it currently gets linked against a *newly loaded* copy
of the GHC package. This would not be a problem, except that the new copy has its
own mutable state that is not shared with that state that has already been initialized by
the original GHC package.

This leads to loaded plugins calling GHC code which pokes the static flags,
and then dying with a panic because the static flags *it* sees are uninitialized.

There are two possible solutions:
  1. Export the symbols from the GHC executable from the GHC library and link
     against this existing copy rather than a new copy of the GHC library
  2. Carefully ensure that the global state in the two copies of the GHC
     library matches

I tried 1. and it *almost* works (and speeds up plugin load times!) except
on Windows. On Windows the GHC library tends to export more than 65536 symbols
(see #5292) which overflows the limit of what we can export from the EXE and
causes breakage.

(Note that if the GHC exeecutable was dynamically linked this wouldn't be a problem,
because we could share the GHC library it links to.)

We are going to try 2. instead. Unfortunately, this means that every plugin
will have to say `reinitializeGlobals` before it does anything, but never mind.

I've threaded the cr_globals through CoreM rather than giving them as an
argument to the plugin function so that we can turn this function into
(return ()) without breaking any plugins when we eventually get 1. working.

The code in here is a bit of a mess.  I've fixed up some
inconsistencies I can see, but it could do with an overhaul.

While we previously checked the safety of safe imported modules we
didn't do this check transitively. This can be a problem when we depend
on a trustworthy module in a package that is no longer trusted, so we
should fail compilation. We already stored in an interface file the
transitive list of packages a module depends on. Now we extend that list
to include a flag saying if we depend on that package being trusted as
well.

This patch was originally developed by Max Bolingbroke, and worked on
further by Austin Seipp.  It allows you to write a Core-to-Core pass
and have it dynamically linked into an otherwise-unmodified GHC, and
run at a place you specify in the Core optimisation pipeline.

Main components:
  - CoreMonad: new types Plugin, PluginPass
               plus a new constructor CoreDoPluginPass in CoreToDo

  - SimplCore: stuff to dynamically load any plugins, splice
    them into the core-to-core pipeline, and invoke them

  - Move "getCoreToDo :: DynFlags -> [CoreToDo]"
      which constructs the main core-to-core pipeline
      from CoreMonad to SimplCore
    SimplCore is the driver for the optimisation pipeline, and it
    makes more sense to have the pipeline construction in the driver
    not in the infrastructure module.

  - New module DynamicLoading: invoked by SimplCore to load any plugins
    Some consequential changes in Linker.

  - New module GhcPlugins: this should be imported by plugin modules; it
    it not used by GHC itself.

This works around a segfault we get when trying to load libiconv.a on
some platforms.

If the GHCi .o lib doesn't exist, load the .a instead

The default language is now Haskell2010, so this was a little odd.
Also, --make is now on by default, so this was largely irrelevant.

The FFI GHCi import lib isn't needed as
compiler/ghci/Linker.lhs + rts/Linker.c link the
interpreted references to FFI to the compiled FFI.
We therefore filter it out so that we don't get
duplicate symbol errors.

We still have
    insertList, insertListWith, deleteList
which aren't in Data.Map, and
    foldRightWithKey
which works around the fold(r)WithKey addition and deprecation.

This major patch implements the new OutsideIn constraint solving
algorithm in the typecheker, following our JFP paper "Modular type
inference with local assumptions".  

Done with major help from Dimitrios Vytiniotis and Brent Yorgey.

We modify fields a lot, so we retain the old value if they aren't forced.

also replace picIsOn with isDynamicGhcLib, as __PIC__ is not the
correct test for whether the GHC library is dynamically linked.

That is, you have to build the library/program without -dynamic first,
to get plain object files, and then build it again with -dynamic.

I still need to check whether any changes to Cabal are required to
make this work.

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

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.