D898 and D1059 implemented a fallback behavior to handle the case
that the end user's iconv installation is broken (typically due to
running inside a chroot in which the necessary locale files and/or
gconv modules have not been installed). In this case, if the
program requests an ASCII locale, GHC's char8 encoding is used
rather than the program failing.

However, silently mangling data like char8 does when the programmer
did not ask for it is poor behavior, for reasons described in D1059.

This commit implements an ASCII encoding and uses it in the fallback
case when iconv is unavailable and the user has requested ASCII.

Test Plan:
Added tests for the encodings defined in Latin1.
Also, manually ran a statically-linked executable of that test
in a chroot and the tests passed (up to the ones that call
mkTextEncoding "LATIN1", since there is no fallback from iconv
for that case yet).

Reviewers: austin, hvr, hsyl20, bgamari

Reviewed By: hsyl20, bgamari

Subscribers: thomie

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

GHC Trac Issues: #7695, #10623

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

Summary:
This patch switches -fPIC on for every invocation of GHC
on OpenBSD/AMD64 platform. The reason is OpenBSD's support
for PIE (PIC for executables) hence -fPIC is also needed
for GHC compiled code.

Fixes #10597

Reviewers: austin

Subscribers: thomie, bgamari

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

Austin Seipp authored 10 years ago and Ben Gamari committed 9 years ago

Summary:
This fixes the usage of `make help` in the top-level and subdirectories.

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

Test Plan: It worked now and didn't before.

Reviewers: hvr

Reviewed By: hvr

Subscribers: thomie

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

Update haddock submodule

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 9 years ago and Ben Gamari committed 9 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 9 years ago and Ben Gamari committed 9 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 9 years ago and Ben Gamari committed 9 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 9 years ago and Ben Gamari committed 9 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 9 years ago and Ben Gamari committed 9 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 9 years ago and Ben Gamari committed 9 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 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

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 9 years ago and Ben Gamari committed 9 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)