| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit splits out a subset of GhcException which do not depend on
pretty printing (SDoc), as a new datatype called
PlainGhcException. These exceptions can be caught as GhcException,
because 'fromException' will convert them.
The motivation for this change is that that the Panic module
transitively depends on many modules, primarily due to pretty printing
code. It's on the order of about 130 modules. This large set of
dependencies has a few implications:
1. To avoid cycles / use of boot files, these dependencies cannot
throw GhcException.
2. There are some utility modules that use UnboxedTuples and also use
`panic`. This means that when loading GHC into GHCi, about 130
additional modules would need to be compiled instead of
interpreted. Splitting the non-pprint exception throwing into a new
module resolves this issue. See #13101
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I consider myself lucky that in my circle of friends, `http` urls (as
opposed to `https` urls) are frowned upon in that we generally
apologize in the rase cases that we share an `http` url.
This pull request changes `http` links into their `https` analogues in
the following places:
* In the GHCI startup message (and parts of the User's Guide, where
there are verbatim transcripts of GHCi sessions).
* In a couple of error messages, asking the user to report a bug.
(I also took the liberty to change a single space before the reportabug
url into two spaces, harmonizing this occurence with the others.)
I'm not trying to start a war. I just had a moment to spare and felt
like preparing this diff. Merge or don't merge as you wish!
Reviewers: bgamari, erikd, simonmar
Subscribers: goldfire, rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we fail to initialize the liker properly, we still set the
`initLinkerDone`. In fact we even set that prior to actually
initializing the linker. However if the linker initialization fails, we
the `Done` state is still true. As such we run into the `Dynamic Linker
not initialised` error. Which while technically corret is confusing as
it pulls the attation away from the real issue.
This change puts the Done state into an MVar, and as such ensureing
that all parallel access needs to wait for the linker to be actually
initialized, or try to re-initilize if it fails.
Reviewers: bgamari, RyanGlScott, simonmar, hvr
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #9868, #10355, #13137, #13607, #13531
Differential Revision: https://phabricator.haskell.org/D5012
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This switches the compiler/ component to get compiled with
-XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
modules.
This is motivated by the upcoming "Prelude" re-export of
`Semigroup((<>))` which would cause lots of name clashes in every
modulewhich imports also `Outputable`
Reviewers: austin, goldfire, bgamari, alanz, simonmar
Reviewed By: bgamari
Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
Differential Revision: https://phabricator.haskell.org/D3989
|
| |
|
|
| |
Our new CPP linter enforces this.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC installs signal handlers in runGhc/runGhcT to handle ^C but it
never uninstalls them.
It can be an issue, especially when using GHC as a library.
Test Plan: validate
Reviewers: bgamari, erikd, austin, simonmar
Reviewed By: bgamari, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2633
GHC Trac Issues: #4162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
statements in GHC.
Test Plan: ./validate
Reviewers: goldfire, austin, hvr, bgamari
Reviewed By: austin, hvr, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2260
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This works in conjunction with D2036 to allow useful debug output before
DynFlags has been initializated.
See #11755.
Reviewers: austin
Reviewed By: austin
Subscribers: thomie, gridaphobe
Differential Revision: https://phabricator.haskell.org/D2037
GHC Trac Issues: #11755
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
(Apologies for the size of this patch, I couldn't make a smaller one
that was validate-clean and also made sense independently)
(Some of this code is derived from GHCJS.)
This commit adds support for running interpreted code (for GHCi and
TemplateHaskell) in a separate process. The functionality is
experimental, so for now it is off by default and enabled by the flag
-fexternal-interpreter.
Reaosns we want this:
* compiling Template Haskell code with -prof does not require
building the code without -prof first
* when GHC itself is profiled, it can interpret unprofiled code, and
the same applies to dynamic linking. We would no longer need to
force -dynamic-too with TemplateHaskell, and we can load ordinary
objects into a dynamically-linked GHCi (and vice versa).
* An unprofiled GHCi can load and run profiled code, which means it
can use the stack-trace functionality provided by profiling without
taking the performance hit on the compiler that profiling would
entail.
Amongst other things; see
https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
Notes on the implementation are in Note [Remote GHCi] in the new
module compiler/ghci/GHCi.hs. It probably needs more documenting,
feel free to suggest things I could elaborate on.
Things that are not currently implemented for -fexternal-interpreter:
* The GHCi debugger
* :set prog, :set args in GHCi
* `recover` in Template Haskell
* Redirecting stdin/stdout for the external process
These are all doable, I just wanted to get to a working validate-clean
patch first.
I also haven't done any benchmarking yet. I expect there to be slight hit
to link times for byte code and some penalty due to having to
serialize/deserialize TH syntax, but I don't expect it to be a serious
problem. There's also lots of low-hanging fruit in the byte code
generator/linker that we could exploit to speed things up.
Test Plan:
* validate
* I've run parts of the test suite with
EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
There are a few failures due to the things not currently implemented
(see above).
Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows preprocessor code calls `runInteractiveProcess` but does
not check if an exception is thrown.
`runInteractiveProcess` calls `CreateProcess` which when given a format
the system loader does not know about
will throw an exception. This is what makes #9399 fail.
Ultimately we should not use any `CreateProcess` based calls but
instead `ShellExecuteEx` as this would allow
us to run applications that the shell knows about instead of just the
loader. More details on #365.
This patch removes `PhaseFailed` and throws `ProgramError` instead.
`PhaseFailed` was largely unneeded since it never gave
very useful information aside from the `errorcode` which was almost
always `1`. `IOErrors` have also been eliminated and `GhcExceptions`
thrown in their place wherever possible.
Updates haddock submodule.
Test Plan:
`./validate` to make sure anything didn't break and
`make TESTS="T365"` to test that an error is now properly thrown
Reviewers: austin, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D1256
GHC Trac Issues: #365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverses some of the work done in #1405, and goes back to the
assumption that the bootstrap compiler understands GHC-haskell.
In particular:
* use MagicHash instead of _ILIT and _CLIT
* pattern matching on I# if possible, instead of using iUnbox
unnecessarily
* use Int#/Char#/Addr# instead of the following type synonyms:
- type FastInt = Int#
- type FastChar = Char#
- type FastPtr a = Addr#
* inline the following functions:
- iBox = I#
- cBox = C#
- fastChr = chr#
- fastOrd = ord#
- eqFastChar = eqChar#
- shiftLFastInt = uncheckedIShiftL#
- shiftR_FastInt = uncheckedIShiftRL#
- shiftRLFastInt = uncheckedIShiftRL#
* delete the following unused functions:
- minFastInt
- maxFastInt
- uncheckedIShiftRA#
- castFastPtr
- panicDocFastInt and pprPanicFastInt
* rename panicFastInt back to panic#
These functions remain, since they actually do something:
* iUnbox
* bitAndFastInt
* bitOrFastInt
Test Plan: validate
Reviewers: austin, bgamari
Subscribers: rwbarton
Differential Revision: https://phabricator.haskell.org/D1141
GHC Trac Issues: #1405
|
|
|
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
