| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This hugs heritage gone away with commit f1dffa0224c9e8dcf1d3908e888e7d683485791b
in 2001
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: tried to find HAVE_BIN_SH in internet, no success
Reviewers: simonmar, austin
Reviewed By: austin
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D117
|
|
|
|
| |
Update Haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change here is to make INCOHERENT slightly more permissive:
if the selected candidate is incoherent
then ignore all unifying candidates
This allows us to move the {-# INCOHERENT #-} pragma from
from instance Typeable (f a)
to Typeable (n:Nat) and Typable (s:Symbol)
where it belongs, and where Trac #9242 said it should be.
I don't think this will affect anyone.
I've updated the user manual.
|
|
|
|
|
| |
Please adjust the perf number on your platform if/when it fails. It
should improve slightly. Updates submodule.
|
|
|
|
|
|
| |
This +4% increase (from -1% before) was caused by 1fc60ea. But that
commit did not cause any other regressions, so I’m not investigating
further.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
New function signal_exit_code hides differences between target platforms
handling of fatal error signals and the applications' exit codes. E.g.
on Linux the application exit code which receives fatal error signal
is encoded as 128 + signal value. On the other hand on Solaris
the application exit code is signal value alone.
Test Plan: validated on Linux and tested on Solaris
Reviewers: austin, simonmar
Reviewed By: simonmar
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D122
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Caught by './validate --slow' in 'ghci/scripts/ghci024'.
Commit 207875293fea07aa90efe215369629b657d1875a changed indentation a bit:
--- ./ghci/scripts/ghci024.stdout 2014-07-31 12:05:34.000000000 +0300
+++ ./ghci/scripts/ghci024.run.stdout 2014-08-07 17:19:23.000000000 +0300
@@ -33,4 +33,4 @@
active package flags: none
~~~~~~~~~~ Testing :show packages, including the ghc package
active package flags:
- -package ghc
+-package ghc
Patch restores indentation.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: passed validate, tested manually
Reviewers: austin, ezyang
Reviewed By: ezyang
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D126
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I bisected the performance difference in Haddock and found it was due to
d6aec63c009c4e57181900eb03847d7dc0fc3c7c, which I accidentally picked up
when updating Haddock 00b8f8c5b378fc679639ebe81238cf42d92aa607. The
performance regression is justified by the fact that we are now actually
processing URLs in Haddock comments that we were not previously, so
there would be more allocation. Time use was not affected.
The TODOs simply reflect the fact that we need updated numbers for
32-bit Linux and Windows. Please add them when you get a chance.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we allocated uniques for strings starting at zero, which
means the tag bits in the unique are zero, which means that printing a
Unique for a string will start with a null byte. This is bad. So
instead, start our numbering with the tag byte as '$' (as in $tring).
This is hard coded so we don't have to worry about the optimizer
reducing the expression.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: hvr, simonmar, austin
Subscribers: simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D123
GHC Trac Issues: #9413
|
| |
|
| |
|
|
|
|
|
|
|
| |
According to the definition of has_side_effets in PrimOp,
raise# clearly has side effects! In practice it makes little
difference becuase the fact that it returns bottom is more
important... but still it's better to say it right.
|
|
|
|
|
|
| |
Mainly in Simplify.rebuildCase. The old code wasn't wrong, but I kept
mis-understanding it. This patch cuts splits out "pure seq" from "strict
let", which makes it much easier to grok.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In fixing Trac #9390 I discovered that I *still* didn't really understand
what the can_fail and has_side_effects properties of a PrimOp mean, precisely.
The big new things I learned are
* has_side_effects needs to be true only of *write* effects,
Reads (which are, strictly speaking, effects) don't matter here.
* has_side_effects must be true of primops that can throw a synchronous
Haskell exception (eg raiseIO#)
* can_fail is true only of primops that can cause an *unchecked* (not
Haskell) system exception, like divide by zero, or accessing memory
out of range through an array read or write.
I've documented all this now. The changes in this patch are only
in comments.
|
|
|
|
|
|
|
|
|
| |
It's not obvious why the simplifier generates code that correctly satisfies
the let/app invariant. This patch does some minor refactoring, but the main
point is to document pre-conditions to key functions, namely that the rhs
passed in satisfies the let/app invariant.
There shouldn't be any change in behaviour.
|
|
|
|
|
|
|
|
|
| |
Vectorise.Generic.PAMethods.buildToArrPReprs was building an expression like
pvoids# (lengthSels2# sels)
which does not satisfy the let/app invariant. It should be more like
case lengthSels2# sels of l -> pvoids# l
This was caught by Core Lint (once it was taught to check for the invariant)
|
|
|
|
|
|
|
|
| |
This is actually the bug that triggered Trac #9390. We had
an unboxed tuple (# writeArray# ..., () #), and that writeArray#
argument isn't ok-for-speculation, so disobeys the invariant.
The desugaring of unboxed tuples was to blame; the fix is easy.
|
|
|
|
|
| |
We were inadvertently destroying the let/app invariant,
by floating into an unlifted function argument.
|
|
|
|
|
|
|
| |
If we have an invariant, Lint should jolly well check it.
(And indeed, adding this test throws up Lint errors that
are fixed in separate patches.)
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue is presented in Makefile logic where it attempts to start
linker_unload and pass it HSinteger-gmp library for unload,
but the library name is prefixed with two directories names. The first
is of ghc's integer-gmp/build itself and another is the directory name
passed to --with-gmp-libraries= configure parameter. The testcase then
fails on unloading integer-gmp/build directory thinking that this is
a library to unload. The issue is solved by cuting (head -1) the first
library name from the list and using this for unloading the HSinteger-gmp
library. I use head -1 instead of cut -d ' ' here since ghc may be
installed into the directory with space(s) in its name like in the case
when running validate.
|
| |
|
|
|
|
| |
Thanks to slyfox for noticing this reregression.
|
|
|
|
| |
This reverts commit 65e5dbcd3971cb3ef5b9073096e5d063034b90c1.
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, if you ran trace "foo\0bar", the output was truncated so
that everything after the null byte was omitted. This was terrible.
Now we filter out null bytes, and emit an extra trace saying that
null bytes were filtered out.
NB: we CANNOT fix debugBelch, because all printf variants *always*
respect null bytes, even if you're using string precision such as
%.*s. The alternative would have been to introduce a new function
debugRawBelch which did not use format strings and took an explicit
string length, but I decided we generally should avoid putting null
bytes in our trace messages, and warn the user.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: hvr, austin
Subscribers: simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D121
GHC Trac Issues: #9395
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Another macro borrowed from hugs, gone aways in
commit 528a7d2cf1c90408d60028bb1fec85124d539476
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: build-tested
Reviewers: simonmar, austin, ezyang
Reviewed By: austin, ezyang
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D118
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch set adds support for extra syntax on -package and related
arguments which allow you to thin and rename modules from a package.
For example, this argument:
-package "base (Data.Bool as Bam, Data.List)"
adds two more modules into scope, Bam and Data.List, without adding
any of base's other modules to scope.
These flags are additive: so, for example, saying:
-hide-all-packages -package base -package "base (Data.Bool as Bam)"
will provide both the normal bindings for modules in base, as well as
the module Bam.
There is also a new debug flag -ddump-mod-map which prints the state
of the module mapping database. H = hidden, E = exposed (so for
example EH says the module in question is exported, but in a hidden
package.)
Module suggestions have been minorly overhauled to work better with reexports:
if you have -package "base (Data.Bool as Bam)" and mispell Bam, GHC
will suggest "Did you mean Bam (defined via package flags to be
base:Data.Bool)"; and generally you will get more accurate information.
Also, fix a bug where we suggest the -package flag when we really need
the -package-key flag.
NB: The renaming afforded here does *not* affect what wired in
symbols GHC generates. (But it does affect implicit prelude!)
ToDo: add 'hiding' functionality, to make it easier to support the alternative
prelude use-case.
ToDo: Cabal support
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: new tests and validate
Reviewers: simonpj, simonmar, hvr, austin
Subscribers: simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D113
GHC Trac Issues: #9375
|
|
|
|
|
|
|
| |
You can parametrize over the different selection by using a
different PackageArg. This helps reduce code duplication.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of building a multiply indirected data structure and querying
it on every import, we now have two data structures moduleToPkgConf
and moduleToPkgConfAll. moduleToPkgConf is a single-level UniqFM that
is intended to be used for most valid imports; however, it does not
contain any information useful for error reporting. If an error is
occurred, we then query moduleToPkgConfAll, which contains a more
comprehensive view of the package database. This field is lazily
initialized (so this means we're retaining the package database list,
but this should be fine because we're already maintaining the entries
of the list.) Additionally, the full view doesn't keep track of a boolean
toggle for visibility/exposure anymore, but instead tracks the *provenance*
of how the module binding came to be (the ModuleOrigin data type).
Additionally, we move the logic for determining if a module is exposed
or not from Finder.lhs and put it in Packages.lhs; this information is
communicated via the LookupResult data type. Unfortunately, we can't
directly return a FindResult, because this data type is defined in
HscTypes which depends on Packages. This is going to change some more
in the near future when I add thinning/renaming to package flags; the
error messages will need to be more flexible.
I've also slightly changed the semantics of error messages for package
qualified imports. Previously, if we didn't find any package qualified
imports, but there were hidden modules in a *different* package, the error
message would prefer mentioning those as opposed to providing suggestions.
Now, if a module is hidden but in the wrong package, we won't mention it;
instead, it will get mentioned with the other module suggestions. I
was too lazy to write a test, but I can add one if people would like.
The module reexport bug was, package q reexported p:P as Conflict,
and package r reexported p:P2 as Conflict, this was *not* reported as
a conflict, because the old logic incorrectly decided that P and P2 were
the same module on account of being from the same package. The logic here
has been corrected.
Contains haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, simonmar, hvr, austin
Subscribers: simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D107
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Duncan requested that ghc-pkg not accept duplicate package IDs (foo-0.1)
by default until the higher level tools can accommodate it. Until then
you'll need to use the --multi-instance flag to install multiple copies in
the package database.
I think reusing the --multi-instance flag is dodgy, because that can be used
to cause duplicate package keys; but there is a mode of use of the database
where package keys are unique.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch set makes us no longer assume that a package key is a human
readable string, leaving Cabal free to "do whatever it wants" to allocate
keys; we'll look up the PackageId in the database to display to the user.
This also means we have a new level of qualifier decisions to make at the
package level, and rewriting some Safe Haskell error reporting code to DTRT.
Additionally, we adjust the build system to use a new ghc-cabal output
Make variable PACKAGE_KEY to determine library names and other things,
rather than concatenating PACKAGE/VERSION as before.
Adds a new `-this-package-key` flag to subsume the old, erroneously named
`-package-name` flag, and `-package-key` to select packages by package key.
RFC: The md5 hashes are pretty tough on the eye, as far as the file
system is concerned :(
ToDo: safePkg01 test had its output updated, but the fix is not really right:
the rest of the dependencies are truncated due to the fact the we're only
grepping a single line, but ghc-pkg is wrapping its output.
ToDo: In a later commit, update all submodules to stop using -package-name
and use -this-package-key. For now, we don't do it to avoid submodule
explosion.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, simonmar, hvr, austin
Subscribers: simonmar, relrod, carter
Differential Revision: https://phabricator.haskell.org/D80
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is in preparation for thinning/renaming package arguments, which allow
users to rename modules of packages they import. In situations like this,
it may be desirable to load multiple copies of a package at different versions
explicitly under different names.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, simonmar, hvr, austin
Subscribers: simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes topHandler03 execution on Solaris where
shell correctly signals SIGTERM as exit status 15.
Test Plan: validate
Reviewers: austin
Reviewed By: austin
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D112
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: austin
Reviewed By: austin
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D114
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The patch names most of RTS threads
and ghc (the tool) threads.
It makes nicer debug and eventlog output for ghc itself.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: ran debugged ghc under '+RTS -Ds'
Reviewers: simonmar, austin
Reviewed By: austin
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch set fixes two issues in linker_unload test case
on Solaris/i386 platform. First there is an issue in linker_unload.c
which causes warning to be emitted about _FILE_OFFSET_BITS redefined.
This is solved by including ghcconfig.h as a first header file.
Another issue is that on Solaris and its builders we use to configure
ghc with --with-gmp-libraries=/usr/lib and this causes issue with
test case Makefile's logic. It attempts to start linker_unload
and pass it HSinteger-gmp library for unload, but the library
name is prefixed with two directories names. The first is of
ghc's integer-gmp/build itself and another is the directory name
passed to --with-gmp-libraries= configure parameter. In case
of Solaris this is /usr/lib. The testcase then fails on unloading
integer-gmp/build directory thinking that this is a library to unload.
This issue is solved by cuting the first library name from the list
and using this for unloading the HSinteger-gmp library.
Test Plan: validate
Reviewers: ezyang, austin
Reviewed By: ezyang, austin
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On hardened gentoo ghc-stage2 does not work as-is,
as it uses runtime code generation/loading, thus
ghc0stage2 needs to be marked in a special way
(via POSIX extened attributes).
Before the patch we used 'cp -p' command, which
does not preserve that marking. It leads to buid
failure on hardened. Hardened's 'install' does
preserve POSIX xattrs, thus patch uses it instead.
'inplace/' directory can be seen the same way as target
for 'make install', thus using the same facilities
to install files to 'inplace/' sounds more consistent.
Reported-by: Jay Yang
Gentoo-bug: https://bugs.gentoo.org/518734
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: tested ghc installation on vanilla and hardened distributions
Reviewers: austin
Reviewed By: austin
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D108
|