| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes the needed changes to make RemoteGHCi work on Windows.
The approach passes OS Handles areound instead of the Posix Fd
as on Linux.
The reason is that I could not find any real documentation about
the behaviour of Windows w.r.t inheritance and Posix FDs.
The implementation with Fd did not seem to be able to find the Fd
in the child process. Instead I'm using the much better documented
approach of passing inheriting handles.
This requires a small modification to the `process` library.
https://github.com/haskell/process/pull/52
Test Plan: ./validate On Windows x86_64
Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
Reviewed By: simonmar
Subscribers: #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D1836
GHC Trac Issues: #11100
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin, thomie, nomeata
Differential Revision: https://phabricator.haskell.org/D1782
GHC Trac Issues: #11433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to simplify the task, the version munging logic has
been radically simplified:
Previously, in cases where the version contained dates as version components,
the build-system would munge the version of the stage1 ghc package before
registering the `ghc` package.
However, this hack was already questionable at the time of its introduction
(c.f. 7b45c46cbabe1288ea87bd9b94c57e010ed17e60).
Simplifying the build-systems by avoiding such hacks may also help the
shaking-up-ghc effort.
So now we simply munge directly via the `.cabal` files, which gives a simpler
picture, as now every stage is munged the same. Munging is only active when
the first patch-level version component is a date. So stable snapshots and release
candidates are unaffacted (as those have the date in the second patch-level
version component)
Reviewers: simonmar, bgamari, austin, thomie, ezyang
Reviewed By: bgamari, thomie, ezyang
Differential Revision: https://phabricator.haskell.org/D1673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds two tests (one for Trac #4340 and one for Trac #10272), as well as
advice on how to fix your code if `hsc2hs` emits warnings with GHC 8.0
due to a redefinition of `#alignment`. (I also put the advice in the
[GHC 8.0 Migration
Guide](https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0).)
Reviewed By: thomie
Differential Revision: https://phabricator.haskell.org/D1663
GHC Trac Issues: #4340, #10272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't just solve CallStack constraints indiscriminately when they
occur in the RHS of a let-binder. The top-level given CallStack (if
any) will not be in scope, so I've re-worked the CallStack solver as
follows:
1. CallStacks are treated like regular IPs unless one of the following
two rules apply.
2. In a function call, we push the call-site onto a NEW wanted
CallStack, which GHC will solve as a regular IP (either directly from a
given, or by quantifying over it in a local let).
3. If, after the constraint solver is done, any wanted CallStacks
remain, we default them to the empty CallStack. This rule exists mainly
to clean up after rule 2 in a top-level binder with no given CallStack.
In rule (2) we have to be careful to emit the new wanted with an
IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
again. This is a bit shady but I've updated the Note to explain the
trick.
Test Plan: validate
Reviewers: simonpj, austin, bgamari, hvr
Reviewed By: simonpj, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1422
GHC Trac Issues: #10845
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1577
|
|
|
|
|
|
|
|
|
| |
With the move to RST-based documentation, there is no need to ignore XML files
in the source tree anymore.
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1554
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit aecf4a5f96d0d3ffcf4cb2c67a20a610d7c64486.
It turns out the Simons are relying on 'mk/are-validating.mk', see
D1307.
The workflow they are using is:
* run ./validate
* find a bug in the compiler
* try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
of 'mk/are-validating.mk', this uses the same build settings as validate.
* continue ./validate (--no-clean)
I suggested two alternatives:
A. run 'make 1 Validating=YES' instead of 'make 1'
Problem: when running `./validate --fast` or `./validate --hpc`
instead of a normal `./validate`, validate sets ValidateSpeed and
ValdateHpc in mk/are-validating.mk. You would for example have to run
'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
same build settings as `./validate --fast`, which is entirely too long and
error prone.
B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
'mk/validate.mk'.
Problems:
* any other settings you have in build.mk will also get used.
* the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
clear.
* it is easy to forget to include 'mk/validate.mk'.
* the build system again doesn't have access to the ValidateSpeed and
ValdateHpc settings set by validate.
Neither of these two options is entirely satisfactory.
Reviewers: austin, bgamari
Differential Revision: https://phabricator.haskell.org/D1383
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
freak out if using a `Data` instance that produces a `Constr` (by means of
`toConstr`) using a function name instead of a data constructor name. While
such `Data` instances are somewhat questionable, they are nevertheless present
in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
aware of their existence.
In order to properly distinguish strings which represent variables (as opposed
to data constructors), it was necessary to move functionality from `Lexeme` (in
`ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
`bin-package-db`).
Reviewed By: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D1313
GHC Trac Issues: #10796
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
| |
A `make` build after running `./validate` earlier should use the normal
mk/build.mk settings, without having to manually delete the leftover
file mk/are-validating or run `make clean` first.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1307
|
| |
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
see Trac #8624
similar functionality is now available
with -ddump-to-file -ddump-splices
However, users are already accustomed to -ddump-splices
having a particular format, and this format is not completely valid code
The goal of -th-file is to dump valid Haskell code
Additionally, the convention of -ddump-to-file is to name the file after
the flag, so the file is .dump-splices
Given that the goal of the new flag is to generate valid Haskell,
The extension should be .hs
Additionally, -ddump-to-file effects all other dump flags
Test Plan:
look at the output of using the -th-file flag
and compare it to the output of using -ddump-to-file and -ddump-splices
I want to add test cases, but just need some pointers on getting started there
Reviewers: thomie, goldfire, simonpj, austin
Reviewed By: simonpj, austin
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D518
GHC Trac Issues: #8624
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
commit id uniquely identifies the state of the GHC source-tree. So
having that information embedded into the `ghc` executable provides
valuable information to track accurately (especially when created by
buildbots) from which source-tree-state a given `ghc` snapshot
(distribution) was generated.
So this commit adds a new field `"Project Git commit id"` to the
`ghc --info` meta-data containing the `./configure`-time Git commit id
as reported by `git rev-parse HEAD`.
This field can also be queried with `ghc --print-project-git-commit-id`.
For source distributions, the file `GIT_COMMIT_ID` is created (with some
sanity checking to detect stale commit ids, as that would render this
information rather useless)
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D528
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
would result in
#define __GLASGOW_HASKELL__ 710
#define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
#define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623
while GHC 7.10.3 results in
#define __GLASGOW_HASKELL__ 710
#define __GLASGOW_HASKELL_PATCHLEVEL1__ 3
and finally GHC 7.9.20141009 results in
#define __GLASGOW_HASKELL__ 709
#define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009
As it's error-prone to properly express CPP conditionals for testing GHC
multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
provided (also via the new CPP include file `ghcversion.h`)
Finally, in order to make it easier to define the new CPP macro
`MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
`include/ghcversion.h` is used for the new CPP definitions.
Reviewed By: ekmett, austin, #ghc
Differential Revision: https://phabricator.haskell.org/D66
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
| |
Auditors: hvr
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, the following sub-repos/modules are converted:
- libffi-tarballs
- libraries/array
- libraries/deepseq
- libraries/directory
- libraries/dph
- libraries/filepath
- libraries/haskell2010
- libraries/haskell98
- libraries/hoopl
- libraries/hpc
- libraries/old-locale
- libraries/old-time
- libraries/parallel
- libraries/process
- libraries/stm
- libraries/unix
- nofib
- utils/hsc2hs
N.B. ghc-tarballs is not converted as it will probably be handled
differently in the future.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
| |
This adapts the top-level .gitignore file to match the new situation of
base.git, ghc-prim.git, integer-gmp.git, integer-simple.git, and
template-haskell.git being folded into ghc.git
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
|
|
|
|
|
|
|
| |
This should help contribute content to
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit performs a subtree merge of testsuite.git into ghc.git;
The next commit will adapt `sync-all` et al. to the new situation.
At the time of merge, testsuite.git was at commit
[998a816ae89c4fd573f4abd7c6abb346cf7ee9af/testsuite]
The following steps have been used to accomplish this merge:
1. Clone a fresh testsuite.git copy (& cd into)
2. Remove accidentally committed binary files from history
git filter-branch \
--index-filter "git rm -r --cached --ignore-unmatch \
tests/haddock/should_compile_flag_nohaddock/a.out \
tests/haddock/should_compile_noflag_nohaddock/a.out \
tests/ghc-regress/haddock/should_compile_flag_nohaddock/a.out \
tests/ghc-regress/haddock/should_compile_noflag_nohaddock/a.out \
tests/ghc-regress/dph/diophantine/dph-diophantine-fast \
tests/ghc-regress/dph/diophantine/dph-diophantine-opt \
tests/ghc-regress/dph/primespj/dph-primespj-fast \
tests/ghc-regress/dph/quickhull/dph-quickhull-fast \
tests/ghc-regress/dph/smvm/dph-smvm \
tests/ghc-regress/dph/sumnats/dph-sumnats \
tests/ghc-regress/dph/words/dph-words-fast \
tests/ghc-regress/plugins/plugins01" \
HEAD
3. Rename all paths in testsuite.git to be prefixed with `testsuite/`
git filter-branch -f --prune-empty --tree-filter \
"mkdir -p testsuite; \
git ls-tree --name-only \$GIT_COMMIT | xargs -I files mv files testsuite/"
4. cd into ghc/ checkout, and perform subtree merge of testsuite into ghc
(see also http://nuclearsquid.com/writings/subtree-merging-and-you/)
cd ../ghc/
git remote add -f testsuite ../testsuite/.git
git merge -s ours --no-commit testsuite/master
git read-tree --prefix=/ -u testsuite/master
git commit
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
| |
I don't think we are using it for anything any more.
|
|
|
|
| |
Looks like I forgot to make it one in the original conversion
|
|
|
|
|
| |
This bring the time package into line with how we handle other
packages.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
We no longer generate those files
|
| |
|
|
|
|
|
|
| |
- Make sure that we have no implicit names in ifaces
- Any vectorisation info makes a module an orphan module
- Allow 'Show' in vectorised code without vectorising it for the moment
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
|