Cheng Shao authored 2 years ago and Marge Bot committed 2 years ago

This patch adds a standalone test case for rts_clearMemory that mimics
how it's typically used by wasm backend users and ensures this RTS API
isn't broken by future RTS refactorings. Fixes #23901.

Andrew Martin authored 5 years ago and Marge Bot committed 4 years ago

This function and its accompanying rule resolve issue #5218.
A future PR to the bytestring library will make the internal
Data.ByteString.Internal.unsafePackAddress compute string length
with cstringLength#. This will improve the status quo because it is
eligible for constant folding.

Additionally, introduce a new data constructor to ForeignPtrContents
named FinalPtr. This additional data constructor, when used in the
IsString instance for ByteString, leads to more Core-to-Core
optimization opportunities, fewer runtime allocations, and smaller
binaries.

Also, this commit re-exports all the functions from GHC.CString
(including cstringLength#) in GHC.Exts. It also adds a new test
driver. This test driver is used to perform substring matches on Core
that is dumped after all the simplifier passes. In this commit, it is
used to check that constant folding of cstringLength# works.

Alexandre R. Baldé authored 6 years ago and Marge Bot committed 5 years ago

    This commit includes the necessary changes in code and
    documentation to support a primop that reverses a word's
    bits. It also includes a test.

Previously, GHC was quite eager to panic whenever it was fed
an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an
explicit error message instead, so this patch accomplishes just that.

Test Plan: make test TEST=T14708

Reviewers: Phyx, hvr, bgamari

Reviewed By: Phyx

Subscribers: thomie, carter

GHC Trac Issues: #9438, #14708, #15032

Differential Revision: https://phabricator.haskell.org/D4589

Summary:
Cabal internal libraries are implemented using a trick, where the 'name'
field in ghc-pkg registration file is munged into a new form to keep
each internal library looking like a distinct package to ghc-pkg and
other tools; e.g. the internal library q from package p is named
z-p-z-q.

Later, Cabal library got refactored so that we made a closer distinction
between these "munged" package names and the true package name of a
package.  Unfortunately, this is an example of a refactor for clarity in
the source code which ends up causing problems downstream, because the
point of "munging" the package name was to make it so that ghc-pkg and
similar tools transparently used MungedPackageName whereever they
previously used PackageName (in preparation for them learning proper
syntax for package name + component name).  Failing to do this meant
that internal libraries from the same package (but with different
names) clobber each other.

This commit search-replaces most occurrences of PackageName in
ghc-pkg and turns them into MungedPackageName. Otherwise there
shouldn't be any functional differenes.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13703

Differential Revision: https://phabricator.haskell.org/D3590

Summary:
If you run `make test` on a non-Windows OS from a fresh build, the
testsuite will create an executable called `TimeMe` which `git` thinks is an
untracked file. Let's add it to `.gitignore` to avoid polluting the list of
untracked files.

Test Plan: Run `make test`, check if `TimeMe` is in the `git` untracked files

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3536

Summary:
This patch implements Backpack for GHC.  It's a big patch but I've tried quite
hard to keep things, by-in-large, self-contained.

The user facing specification for Backpack can be found at:

    https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst

A guide to the implementation can be found at:

    https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst



Has a submodule update for Cabal, as well as a submodule update
for filepath to handle more strict checking of cabal-version.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, simonmar, bgamari, goldfire

Subscribers: thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D1482

rcook authored 8 years ago and Ben Gamari committed 8 years ago

In outHsLine, paths passed to construct invocations of hsc_line must be
escaped twice in order to generate a properly escaped string literal
that will end up in the eventual LINE pragma emitted by this code. This
is especially important on Windows paths, where backslashes would
otherwise be treated as C escape sequences and result in the incorrect
Windows paths.

Adds test case to verify that hsc2hs properly escapes file paths in LINE
pragmas

Updates the hsc2hs submodule.

See https://ghc.haskell.org/trac/ghc/ticket/12504

Reviewers: erikd, hvr, austin, bgamari, Phyx

Reviewed By: erikd, Phyx

Subscribers: thomie, Phyx, mpickering

Differential Revision: https://phabricator.haskell.org/D2478

GHC Trac Issues: #12504

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: thomie, austin, bgamari

Reviewed By: bgamari

Subscribers: hvr

Differential Revision: https://phabricator.haskell.org/D2058

GHC Trac Issues: #11763

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

The shadowing and default behavior (in the absence of
-hide-all-packages) prefers packages that come from "later" package
databases.  So for example if tmp1.d and tmp2.d both expose p-1.0, then

    ghc -package-db tmp1.d -package-db tmp2.d

brings the p-1.0 from tmp2.d into scope (and if they have the same IPID,
tmp2.d shadows tmp1.d).  HOWEVER, -package flags do NOT respect this
behavior.

    ghc -package-db tmp1.d -package-db tmp2.d -package p-1.0

this will force the p-1.0 from tmp1.d to be exposed!  This is
confusing, so this patch makes the behavior of -package flags
consistent.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1709

This introduces "freezing," an operation which prevents further
locations from being appended to a CallStack.  Library authors may want
to prevent CallStacks from exposing implementation details, as a matter
of hygiene. For example, in

```
head [] = error "head: empty list"

ghci> head []
*** Exception: head: empty list
CallStack (from implicit params):
  error, called at ...
```

including the call-site of `error` in `head` is not strictly necessary
as the error message already specifies clearly where the error came
from.

So we add a function `freezeCallStack` that wraps an existing CallStack,
preventing further call-sites from being pushed onto it. In other words,

```
pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack
```

Now we can define `head` to not produce a CallStack at all

```
head [] =
  let ?callStack = freezeCallStack emptyCallStack
  in error "head: empty list"

ghci> head []
*** Exception: head: empty list
CallStack (from implicit params):
  error, called at ...
```

---

1. We add the `freezeCallStack` and `emptyCallStack` and update the
   definition of `CallStack` to support this functionality.

2. We add `errorWithoutStackTrace`, a variant of `error` that does not
   produce a stack trace, using this feature. I think this is a sensible
   wrapper function to provide in case users want it.

3. We replace uses of `error` in base with `errorWithoutStackTrace`. The
   rationale is that base does not export any functions that use CallStacks
   (except for `error` and `undefined`) so there's no way for the stack
   traces (from Implicit CallStacks) to include user-defined functions.
   They'll only contain the call to `error` itself. As base already has a
   good habit of providing useful error messages that name the triggering
   function, the stack trace really just adds noise to the error. (I don't
   have a strong opinion on whether we should include this third commit,
   but the change was very mechanical so I thought I'd include it anyway in
   case there's interest)

4. Updates tests in `array` and `stm` submodules

Test Plan: ./validate, new test is T11049

Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari

Reviewed By: simonpj

Subscribers: thomie

Projects: #ghc

Differential Revision: https://phabricator.haskell.org/D1628

GHC Trac Issues: #11049

Added test and changed -Nmax to -maxN, -n was taken

Noticed strange -m behavoir and fixed -m from quietly
ignoring being passed invalid opts, e.g. "-msasd"

Reviewers: simonmar, hvr, austin, thomie, bgamari

Reviewed By: hvr, thomie, bgamari

Subscribers: bgamari, hvr, thomie, simonmar

Differential Revision: https://phabricator.haskell.org/D1677

GHC Trac Issues: #10728

Summary:
The basic idea is that we have a new set of "exposed modules"
which are /only/ used for plugins, i.e. -fplugin Foo and
--frontend Foo.  You can interact with this namespace
using the flags -plugin-package-id and -plugin-package.
By default, this namespace contains all modules in the
user namespace (as before), but you can toggle that using
-hide-all-plugin-packages.

There is one nasty hack: GhcMake respects -fplugin in
GHC_OPTIONS to make local plugins work correctly.  It also
bails out of you have an import of a module which doesn't
exist locally or in the package database.  The upshot is
that we need to be sure to check in the plugin modules
too, so we don't give a spurious failure when a plugin
is in the plugin namespace but not the main namespace.
A better way to fix this would be to distinguish between
plugin and normal dependencies in ModSummary.

I cheated a little and tweaked a few existing plugins
tests to exercise the new code paths.

TODO: Documentation

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin, simonpj, duncan

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1661

GHC Trac Issues: #11244

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

Summary:
Frontend plugins enable users to write plugins to replace
GHC major modes.  E.g. instead of saying

    ghc --make A B C

a user can now say

    ghc --frontend GHC.Frontend.Shake A B C

which might provide an alternative implementation of a multi-module
build.  For more details, see the manual entry.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonmar, bgamari, austin, simonpj

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1598

GHC Trac Issues: #11194

roshats authored 9 years ago and Ben Gamari committed 9 years ago

Reviewers: austin, thomie, bgamari

Reviewed By: thomie, bgamari

Subscribers: mpickering, thomie

Differential Revision: https://phabricator.haskell.org/D1518

GHC Trac Issues: #9015

The tests weren't explicit enough about comparing under different
unique allocation strategies. This led to some confusion on my part when
I started overriding flags in `testsuite/mk/test.mk`.
Includes a `.gitignore` rule.

Test Plan: harbormaster

Reviewers: austin, simonmar, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1555

Erik de Castro Lopo authored 9 years ago and Ben Gamari committed 9 years ago

Test Plan: Test on Arm and PowerPc.

Reviewers: bgamari, thomie, austin

Differential Revision: https://phabricator.haskell.org/D1510

GHC Trac Issues: #11060

This sneaked in via 2325bd4e / D1468 / #4012

This is frustrating... we've added a useless 2.4MiB binary blob to our
Git history which wastes *everyones* bandwidth for eternity
(unless we truncate or rewrite history).

We should add lint-checks and/or a pre-receive commit hook test to prevent
this in future.

Summary:
This reverts commit 06d46b1e.

This also has a Haddock submodule update.

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1475

Thomas Miedema authored 9 years ago and Ben Gamari committed 9 years ago

Test Plan: it works

Reviewers: bgamari, rwbarton, austin

Reviewed By: austin

Subscribers: rwbarton

Differential Revision: https://phabricator.haskell.org/D1377

Test Plan: validate

Reviewers: austin, thomie, bgamari

Reviewed By: thomie

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1349

GHC Trac Issues: #10970

This commit contains a Cabal submodule update which unifies installed
package IDs and package keys under a single notion, a Component ID.
We update GHC to keep follow this unification.  However, this commit
does NOT rename installed package ID to component ID and package key to
unit ID; the plan is to do that in a companion commit.

    - Compiler info now has "Requires unified installed package IDs"

    - 'exposed' is now expected to contain unit keys, not IPIDs.

    - Shadowing is no more.  We now just have a very simple strategy
      to deal with duplicate unit keys in combined package databases:
      if their ABIs are the same, use the latest one; otherwise error.
      Package databases maintain the invariant that there can only
      be one entry of a unit ID.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari, hvr, goldfire

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1184

GHC Trac Issues: #10714

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This patch drops the file level distinction between hs-boot and hsig;
we figure out which one we are compiling based on whether or not there
is a corresponding hs file lying around.

To make the "import A" syntax continue to work for bare hs-boot
files, we also introduce hs-boot merging, which takes an A.hi-boot
and converts it to an A.hi when there is no A.hs file in scope.
This will be generalized in Backpack to merge multiple A.hi files together;
which means we can jettison the "load multiple interface files" functionality.

This works automatically for --make, but for one-shot compilation
we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
from a local A.hi-boot file; Backpack will extend this mechanism further.

Has Haddock submodule update to deal with change in msHsFilePath behavior.

    - This commit drops support for the hsig extension. Can
      we support it?  It's annoying because the finder code is
      written with the assumption that where there's an hs-boot
      file, there's always an hs file too.  To support hsig, you'd
      have to probe two locations.  Easier to just not support it.

    - #10333 affects us, modifying an hs-boot still doesn't trigger
      recomp.

    - See compiler/main/Finder.hs: this diff is very skeevy, but
      it seems to work.

    - This code cunningly doesn't drop hs-boot files from the
      "drop hs-boot files" module graph, if they don't have a
      corresponding hs file.  I have no idea if this actually is useful.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari, spinda

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1098

This reverts commit 214596de.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Eric Seidel authored 9 years ago and Thomas Miedema committed 9 years ago

I didn't realize that `./validate` does not run every test :(

Test Plan: ./validate --slow

Update submodule hpc.

Differential Revision: https://phabricator.haskell.org/D1204

Test Plan: validate

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, thomie

Differential Revision: https://phabricator.haskell.org/D1116

GHC Trac Issues: #10481

This reverts commit bac927b9.

As it turns out, we need these commits for separate compilation
and accurate dependency tracking.  So back in they go!

* don't print anything to stdout
* add missing Makefile
* also ignore mk/ghcconfig*.mk when using installed compiler
* prevent warning: -rtsopts and -with-rtsopts have no effect with -shared

rwbarton authored 9 years ago and Ben Gamari committed 9 years ago

In a parallel program they can actually be entered more than once,
leading to deadlock.

Reviewers: austin, simonmar

Subscribers: michaelt, thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1040

GHC Trac Issues: #10414

Summary:
On x86_64, commit e2f6bbd3 assigned
the STG registers F1 and D1 the same hardware register (xmm1), and
the same for the registers F2 and D2, etc. When mixing calls to
functions involving Float#s and Double#s, this can cause wrong Cmm
optimizations that assume the F1 and D1 registers are independent.

Reviewers: simonpj, austin

Reviewed By: austin

Subscribers: simonpj, thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D993

GHC Trac Issues: #10521

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Summary:
If we have an orphan rule in our database, don't apply it
unless the defining module is transitively imported by the
module we are processing.  We do this by defining a new RuleEnv
data type which includes both the RuleBase as well as the set
of visible orphan modules, and threading this through the
relevant environments (CoreReader, RuleCheckEnv and ScEnv).

This is analogous to the instances fix we applied in #2182
4c834fdd, but done for RULES.
An important knock-on effect is that we can remove some buggy
code in LoadInterface which tried to avoid loading interfaces
that were loaded by plugins (which sometimes caused instances
and rules to NEVER become visible).

One note about tests: I renamed the old plugins07 test to T10420
and replaced plugins07 with a test to ensure that a plugin
import did not cause new rules to be loaded in.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, goldfire

Subscribers: bgamari, thomie

Differential Revision: https://phabricator.haskell.org/D950

GHC Trac Issues: #10420