Incredibly enough this hasn't been touched since 6.10.1

We now only handle ascii ourselves if iconv is unavailable.

IPs with this type will always be solved for the current source
location. If another IP of the same type is in scope, the two locations will be
appended, creating a call-stack. The Location type is kept abstract so users
cannot create them, but a Location can be turned into a list of SrcLocs, which
correspond to individual locations in a program. Each SrcLoc contains a
package/module/file name and start/end lines and columns.

The only thing missing from the SrcLoc in my opinion is the name of the
top-level definition it inhabits. I suspect that would also be useful, but it's
not clear to me how to extract the current top-level binder from within the
constraint solver. (Surely I'm just missing something here?)

I made the (perhaps controversial) decision to have GHC completely ignore
the names of Location IPs, meaning that in the following code:

    bar :: (?myloc :: Location) => String
    bar = foo

    foo :: (?loc :: Location) => String
    foo = show ?loc

if I call `bar`, the resulting call-stack will include locations for

1. the use of `?loc` inside `foo`,
2. `foo`s call-site inside `bar`, and
3. `bar`s call-site, wherever that may be.

This makes Location IPs very special indeed, and I'm happy to change it if the
dissonance is too great.

I've also left out any changes to base to make use of Location IPs, since there
were some concerns about a snowball effect. I think it would be reasonable to
mark this as an experimental feature for now (it is!), and defer using it in
base until we have more experience with it. It is, after all, quite easy to
define your own version of `error`, `undefined`, etc. that use Location IPs.

Test Plan: validate, new test-case is testsuite/tests/typecheck/should_run/IPLocation.hs

Reviewers: austin, hvr, simonpj

Reviewed By: simonpj

Subscribers: simonmar, rodlogic, carter, thomie

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



GHC Trac Issues: #9049

Cherry-Picked-From: c024af13
Cherry-Picked-By: Niklas Hambüchen <niklas@fpcomplete.com>

Changes for the cherry-pick:

* Commit d2b6e767 "Make the location in TcLclEnv and CtLoc into a RealSrcSpan"
  was cherry-picked before to ensure that
    EvCsPushCall, EvCsTop :: EvCallStack
  can indeed carry `RealSrcSpan`s instead of `SrcSpan`s.
* The use of `setWantedEvBind` was replaced by `setEvBind`, as
  `setWantedEvBind` is not yet present in 7.10.1; it was added to
  the 7.12 series in commit 32973bf3.
* docs/users_guide/7.10.1-notes.xml was adjusted to contain the
  documentation about CallStack, copied from the 7.12 notes.

Previously it was a SrcSpan, which can be an UnhelpulSrcSpan,
but actually for TcLclEnv and CtLoc we always know it is
a real source location, and it's good to make the types
reflect that fact.

There is a continuing slight awkwardness (not new with this
patch) about what "file name" to use for GHCi code.  Current
we say "<interactive>" which seems just about OK.

This fixes trac Trac #10638.

SpecConstr was generating a rule LHS with nested casts,
which the simplifier then optimised away.  Result: unbound
template variables.

Easily fixed.  See Note [SpecConstr call patterns]

This was causing Trac #10627.
See Note [Substitute lazily] in CoreSubst.

The bug was introduced by
   commit 30c17e70
    Author: simonpj@microsoft.com <unknown>
    Date:   Thu Nov 25 17:23:56 2010 +0000
    Substitution should just substitute, not optimise

The fix is not to optimise the RHS as well as not-optimising the LHS!
The simplifier does the right thing in Simplify.simplRule

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

Easy fix in the parser to stop regressions, due to Unicode 7.0 changing
the classification of some prior code points.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: `tests/parser/should_compile/T10196.hs`

Reviewers: hvr, austin, bgamari

Reviewed By: austin, bgamari

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10196

Ben Gamari authored 10 years ago and Ben Gamari committed 10 years ago

See Trac #10624.

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

Reviewed By: austin

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

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

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #10624

Ben Gamari authored 10 years ago and Ben Gamari committed 10 years ago

D898 was primarily intended to fix hangs in the event that iconv was
unavailable (namely #10298 and #7695). In addition to this fix, it also
introduced self-contained handling of ANSI terminals to allow compiled
executables to run in minimal environments lacking iconv.

However, the behavior that the patch introduced is highly suspicious.
Specifically, it gives the user a UTF-8 encoding even if they requested
ASCII.

This has the potential to break quite a lot of code. At very least it
breaks GHC's Unicode terminal detection logic, which attempts to catch
an invalid character when encoding a pair of smart-quotes. Of course,
this exception will never be thrown if a UTF-8 encoder is used.

Here we use the `char8` encoding to handle requests for ASCII encodings.

Fixes #10623.

Ben Gamari authored 10 years ago and Ben Gamari committed 10 years ago

This seems to have been changed in
07282c72 to include Unicode quotes
despite the fact that we explicitly set LC_ALL=C in the Makefile to
request standard ASCII output.

Ben Gamari authored 10 years ago and Ben Gamari committed 10 years ago

These are fairly small changes. I'm just going to recenter these and
then focus on identifying the reason for the drift on master

After a struggle, I fixed Trac #5113 (again) on the 7.10 branch,
by adding an ambient substitution to Subst; see CoreSubst,
esp Note [IdSubstEnv].

This allowed me to do the impedence-matching in SimplEnv.substExpr
efficiently (fixing #10370) as well correctly (fixing the latest
problem with #5113).

This cost me more time than I like to say.  Sigh.

Reported by mitchty:

  When porting ghc to alpine linux (rumors say they build
  all binaries as Position Independent Executables
  to leverage global ASLR) linker issued obscure errors:

Tiny example:
    $ echo 'main = print "hello"' > a.hs
    $ ghc -fforce-recomp a.hs -fPIC -dynamic -optl-pie -o a
        ld: /tmp/ghc2142_0/ghc2142_5.o: relocation R_X86_64_32 against `ZCMain_main_closure'
            can not be used when making a shared object; recompile with -fPIC
        /tmp/ghc2142_0/ghc2142_5.o: error adding symbols: Bad value
        collect2: error: ld returned 1 exit status

There is two entry points in CC driver:
    'runPhase' (CC) and 'mkExtraObj'

'mkExtraObj' does not handle most of 'runPhase's complexity.
Ideally it should.

This patch only adds -fPIC propagation to 'mkExtraObj'.

Please merge to stable branch.

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

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

In commit 7d519dab, the file
T4945.stdout was added to the repository, to make T4945 pass
validatation presumably.

When that test produces output however, there is a bug somewhere, and we
shouldn't hide it. There is a comment in the Makefile which says:

    "When SpecConstr works there are no STUArrays at all"

So here we remove T4945.stdout again, mark T4945 as expect_broken, and
reopen the ticket.

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

Conflicts:
	testsuite/tests/simplCore/should_compile/T4945.stdout
	testsuite/tests/simplCore/should_compile/all.T

Signed-off-by: Ben Gamari <ben@smart-cactus.org>

rwbarton authored 10 years ago and Ben Gamari committed 10 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

Conflicts:
	testsuite/tests/codeGen/should_run/all.T

It turned out that the terrible compiler performance in
Trac #10527 arose because we were simplifying a function
argument that subseuqently was discarded, so the work was
wasted.  Moreover, the work turned out to be substantial;
indeed it made an asymptotic difference to compile time.

Ths solution in this 7.10 branch is a bit brutal; just
duplicate CoreSubst.substExpr to be SimplEnv.substExprS.
It works fine I'm working on a better solution for HEAD.

Ben Gamari authored 10 years ago and Ben Gamari committed 10 years ago

When examining compile times for code with large ADTs (particularly those with
many record constructors), I found that the specialiser contributed
disproportionately to the compiler runtime. Some profiling suggested that
the a great deal of time was being spent in `pair_fvs` being called from
`consDictBind`.

@simonpj pointed out that `flattenDictBinds` as called by `specBind` was
unnecessarily discarding cached free variable information, which then needed to
be recomputed by `pair_fvs`.

Here I refactor the specializer to retain the free variable cache whenever
possible.

**Open Qustions**

 * I used `fst` in a couple of places to extract the bindings from a `DictBind`.
   Perhaps this is a sign that `DictBind` has outgrown its type synonym status?

Test Plan: validate

Reviewers: austin, simonpj

Reviewed By: simonpj

Subscribers: thomie, bgamari, simonpj

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

GHC Trac Issues: #7450

Summary:
This fixes test cases T10019 and T10534

The patch for T10019 should be back-ported to master as well.

Posting via Phab as a way to distribute a patch against the
ghc-7.10 branch, which I don't have push access to.

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, bgamari, mzero

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

Summary:
Previously when the split was performed in splitBang, `BangPat` was given the
same SrcSpan as the whole of the LHS of the declaration. This patch
correctly calculates the value.

Reviewers: alanz, austin

Reviewed By: alanz, austin

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10588

(cherry picked from commit c6bb2fc5)

Signed-off-by: Austin Seipp <austin@well-typed.com>

Combining functional dependencies with kind-polymorphism is
devilishly tricky!  It's all documented in
    Note [Closing over kinds in coverage]

Fixes Trac #10564

(cherry picked from commit 7c07cf16)

yieldCapability() was not prepared to be called by a Task that is not
either a worker or a bound Task.  This could happen if we ended up in
yieldCapability via this call stack:

performGC()
scheduleDoGC()
requestSync()
yieldCapability()

and there were a few other ways this could happen via requestSync.
The fix is to handle this case in yieldCapability(): when the Task is
not a worker or a bound Task, we put it on the returning_workers
queue, where it will be woken up again.

Summary of changes:

* `yieldCapability`: factored out subroutine waitForWorkerCapability`
* `waitForReturnCapability` renamed to `waitForCapability`, and
  factored out subroutine `waitForReturnCapability`
* `releaseCapabilityAndQueue` worker renamed to `enqueueWorker`, does
  not take a lock and no longer tests if `!isBoundTask()`
* `yieldCapability` adjusted for refactorings, only change in behavior
  is when it is not a worker or bound task.

Test Plan:
* new test concurrent/should_run/performGC
* validate

Reviewers: niteria, austin, ezyang, bgamari

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10545

(cherry picked from commit 111ba4be)

getNewNursery() was unconditionally incrementing next_nursery, which
is normally fine but it broke an assumption in
storageAddCapabilities().  This manifested as an occasional crash in
the setnumcapabilities001 test.

(cherry picked from commit be0ce871)

(cherry picked from commit a7eee0d8)

... by entirely replacing the use of CPP by a custom preprocessor;
clang -E -traditional has no stringification mechanism at all.

Reviewed By: thomie, austin

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

GHC Trac Issues: #9399

(cherry picked from commit b98ca17e)

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

(cherry picked from commit a2f828a3)

Commit a93ab43a
enabled support for proper PIC relocations from
assembler.

Commit adds support for relocations of type:
    R_PPC_REL16_HI
    R_PPC_REL16_HA
    R_PPC_REL16_LO
    R_PPC_PLTREL24

They are used only when GHC is built in
    DYNAMIC_GHC_PROGRAMS = NO
mode.

Verified by running the following test:

    // cat a.c
    #include <stdio.h>

    void ffi_a_hello (int i) {
        fprintf (stderr, "WEEEEEEEE: i=%d\n", i);
    }

    -- cat A.hs
    {-# LANGUAGE ForeignFunctionInterface #-}
    module A where

    import Foreign.C

    foreign import ccall "ffi_a_hello" a :: CInt -> IO ()

    # ghc -fPIC -c a.c -fforce-recomp
    # ghc -fPIC -c A.hs -fforce-recomp
    # ghc --interactive ./a.o A
    ...
    *A> a 42
    WEEEEEEEE: i=42
See gory details in Trac #10402.

Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Reviewed By: bgamari, austin

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

GHC Trac Issues: #10402

(cherry picked from commit c0847967)

Reviewers: austin, thomie, alanz

Reviewed By: thomie, alanz

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10556

(cherry picked from commit 38f37457)

Summary:
Parsing

    {-# LANGUAGE TupleSections #-}

    baz = (1, "hello", 6.5,,) 'a' (Just ())

Results in the following AST fragment

    (L tests/examples/Tuple.hs:3:7-25
       (ExplicitTuple
          [ L tests/examples/Tuple.hs:3:8
              (Present
                 (L tests/examples/Tuple.hs:3:8
                    (HsOverLit
                       (OverLit
                          (HsIntegral [ '1' ] 1)
                          PlaceHolder
                          (HsLit
                             (HsString
                                []
                                {abstract:FastString}))
                          PlaceHolder))))
          , L tests/examples/Tuple.hs:3:11-17
              (Present
                 (L tests/examples/Tuple.hs:3:11-17
                    (HsLit
                       (HsString
                          [ '"'
                          , 'h'
                          , 'e'
                          , 'l'
                          , 'l'
                          , 'o'
                          , '"'
                          ]
                          {abstract:FastString}))))
          , L tests/examples/Tuple.hs:3:20-22
              (Present
                 (L tests/examples/Tuple.hs:3:20-22
                    (HsOverLit
                       (OverLit
                          (HsFractional
                             (FL
                                [ '6' , '.' , '5' ]
                                (:% 13 2)))
                          PlaceHolder
                          (HsLit
                             (HsString
                                []
                                {abstract:FastString}))
                          PlaceHolder))))
          , L tests/examples/Tuple.hs:3:24
              (Missing PlaceHolder)
          , L tests/examples/Tuple.hs:3:24
              (Missing PlaceHolder)
          ]

The final `Missing PlaceHolder` has a duplicated `SrcSpan`

Test Plan: ./validate

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, bgamari, mpickering

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

GHC Trac Issues: #10537

(cherry picked from commit 72b21c39)

As discussed in #10194, this patch - while fixing a bug - also causes a
minor regression when compiling certain in-the-wild programs, meaning
some extant programs now failed with 7.10.2 RC1. Womp womp.

This reverts commit 681d82c0.

This was a nasty, long-standing bug exposed in Trac #10538.
Symptoms were that we had an empty case
   case (x :: Either a) of {}
Core Lint correctly picked this bogus code up.

Here is what happened

* In SimplUtils.prepareAlts, we call
        filterAlts
  then
        combineIdenticalAlts

* We had    case x of { Left _ -> e1; Right _ -> e1 }

* filterAlts did nothing, but correctly retuned imposs_deflt_cons
  saying that 'x' cannot be {Left, Right} in the DEFAULT branch,
  if any (there isn't one.)

* combineIdentialAlts correctly combines the identical alts, to give
     case x of { DEFAULT -> e1 }

* BUT combineIdenticalAlts did no adjust imposs_deft_cons

* Result: when compiling e1 we did so in the belief that 'x'
  could not be {Left,Right}.  Disaster.

Easily fixed.

(It is hard to trigger; I can't construct a simple test case.)

(cherry picked from commit 023a0ba9)

See Note [writeAtomic leaky abstraction].

GHC on Linux already received a patch for this bug in
e0801a0f. On Windows several cabal tests
were hitting the bug, causing validate failures, but we never noticed
because of all the other tests that were failing on Windows. And it
didn't start happening till `getModificationTime` received sub-second
resolution support on Windows in
5cf76186.

Since there are regression tests already, I am not adding another one.
But for good measure, here is a script that shows the bug without
needing to do a full validate run:

  DB=/tmp/package.conf.d.test
  GHC_PKG=ghc-pkg #utils/ghc-pkg/dist/build/tmp/ghc-pkg
  LOCAL_GHC_PKG="${GHC_PKG} --no-user-package-db --global-package-db=${DB}"
  while true; do
    rm -rf ${DB}
    ${LOCAL_GHC_PKG} init "${DB}"
    ${LOCAL_GHC_PKG} list
  done

If you see "WARNING: cache is out of date" after a few seconds, the bug
is not fixed.

Reviewed By: austin

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

GHC Trac Issues: #10205

(cherry picked from commit f0636562)