| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The current implementation is rather pessimistic. The persistent
linker state is now an MVar and all exported Linker functions are
wrapped in modifyMVar calls. This is serves as a big lock around all
linker functions.
There might be a chance for more concurrency in a few places. E.g.,
extending the closure environment and loading packages might be
independent in some cases. But for now it's better to be on the safe
side.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Also, look for libXXX.dll in addition to XXX.dll (see #1883, this
isn't really a proper fix, but it'll help in some cases).
And I tidied up the error message for a DLL load failure, though it's
still a bit of a mess because addDLL is supposed to return a (static)
string with the error message, but this isn't possible on Windows.
|
| | |
|
| |
|
|
|
| |
TopHandler now uses the new extensible exceptions module, so we
need to interact with it using the new types.
|
| | |
|
| | |
|
| |
|
|
| |
These are needed for GLOBAL_VAR's to work properly
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Try to load interfaces in getLinkDeps
|
| | |
|
