[Git][ghc/ghc][ghc-8.8] 44 commits: Enable external interpreter when TH is requested but no internal interpreter is available

Ben Gamari gitlab at gitlab.haskell.org
Mon Jun 10 05:43:45 UTC 2019 


Ben Gamari pushed to branch ghc-8.8 at Glasgow Haskell Compiler / GHC


Commits:
07131494 by Alp Mestanogullari at 2019-06-04T03:41:36Z
Enable external interpreter when TH is requested but no internal interpreter is available


(cherry picked from commit e172a6d127a65b945b31306ff7b6c43320debfb4)
- - - - -
5d68a56b by Alec Theriault at 2019-06-04T03:41:59Z
RTS: Fix restrictive cast

Commit e75a9afd2989e0460f9b49fa07c1667299d93ee9 added an `unsigned` cast
to account for OSes that have signed `rlim_t` signed. Unfortunately,
the `unsigned` cast has the unintended effect of narrowing `rlim_t` to
only 4 bytes. This leads to some spurious out of memory crashes
(in particular: Haddock crashes with OOM whenn building docs of
`ghc`-the-library).

In this case, `W_` is a better type to cast to: we know it will be
unsigned too and it has the same type as `*len` (so we don't suffer from
accidental narrowing).

- - - - -
551c4024 by Daniel Gröber at 2019-06-04T03:42:11Z
Add hPutStringBuffer utility

- - - - -
0f9ec9d1 by Daniel Gröber at 2019-06-04T03:42:11Z
Allow using tagetContents for modules needing preprocessing

This allows GHC API clients, most notably tooling such as
Haskell-IDE-Engine, to pass unsaved files to GHC more easily.

Currently when targetContents is used but the module requires preprocessing
'preprocessFile' simply throws an error because the pipeline does not
support passing a buffer.

This change extends `runPipeline` to allow passing the input buffer into
the pipeline. Before proceeding with the actual pipeline loop the input
buffer is immediately written out to a new tempfile.

I briefly considered refactoring the pipeline at large to pass around
in-memory buffers instead of files, but this seems needlessly complicated
since no pipeline stages other than Hsc could really support this at the
moment.

- - - - -
fa06d1c5 by Daniel Gröber at 2019-06-04T03:42:11Z
downsweep: Allow TargetFile not to exist when a buffer is given

Currently 'getRootSummary' will fail with an exception if a 'TargetFile' is
given but it does not exist even if an input buffer is passed along for
this target.

In this case it is not necessary for the file to exist since the buffer
will be used as input for the compilation pipeline instead of the file
anyways.

- - - - -
679d9958 by Daniel Gröber at 2019-06-04T03:42:11Z
Export GhcMake.downsweep

This is to enable #10887 as well as to make it possible to test downsweep
on its own in the testsuite.

- - - - -
0cdd6459 by Daniel Gröber at 2019-06-04T03:42:11Z
Add failing test for #10887

- - - - -
f984a86d by Daniel Gröber at 2019-06-04T03:42:11Z
Move throwErrors to HscTypes

This, among other things, happened in 1ffee940a0 ("Fix warnings and fatal
parsing errors") on master.

- - - - -
ae2e6b57 by Daniel Gröber at 2019-06-04T03:42:11Z
Refactor downsweep to allow returning multiple errors per module

- - - - -
35f9fdae by Daniel Gröber at 2019-06-04T03:42:11Z
Refactor summarise{File,Module} to reduce code duplication

- - - - -
01bb7ec3 by Daniel Gröber at 2019-06-04T03:42:11Z
Refactor summarise{File,Module} to extract checkSummaryTimestamp

This introduces a slight change of behaviour in the interrest of keeping
the code simple: Previously summariseModule would not call
addHomeModuleToFinder for summaries that are being re-used but now we do.

We're forced to to do this in summariseFile because the file being
summarised might not even be on the regular search path! So if GHC is to
find it at all we have to pre-populate the cache with its location. For
modules however the finder cache is really just a cache so we don't have to
pre-populate it with the module's location.

As straightforward as that seems I did almost manage to introduce a bug (or
so I thought) because the call to addHomeModuleToFinder I copied from
summariseFile used to use `ms_location old_summary` instead of the
`location` argument to checkSummaryTimestamp. If this call were to
overwrite the existing entry in the cache that would have resulted in us
using the old location of any module even if it was, say, moved to a
different directory between calls to 'depanal'.

However it turns out the cache just ignores the location if the module is
already in the cache. Since summariseModule has to search for the module,
which has the side effect of populating the cache, everything would have
been fine either way.

Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.

- - - - -
23f8525f by Daniel Gröber at 2019-06-04T03:42:11Z
Make downsweep return all errors per-module instead of throwing some

This enables API clients to handle such errors instead of immideately
crashing in the face of some kinds of user errors, which is arguably quite
bad UX.

Fixes #10887

- - - - -
c2707d27 by Daniel Gröber at 2019-06-04T03:42:12Z
Catch preprocessor errors in downsweep

This changes the way preprocessor failures are presented to the
user. Previously the user would simply get an unlocated message on stderr
such as:

    `gcc' failed in phase `C pre-processor'. (Exit code: 1)

Now at the problematic source file is mentioned:

    A.hs:1:1: error:
        `gcc' failed in phase `C pre-processor'. (Exit code: 1)

This also makes live easier for GHC API clients as the preprocessor error
is now thrown as a SourceError exception.

- - - - -
693d8b95 by Daniel Gröber at 2019-06-04T03:42:12Z
PartialDownsweep: Add test for import errors

- - - - -
0072499f by Daniel Gröber at 2019-06-04T03:42:12Z
Add depanalPartial to make getting a partial modgraph easier

As per @mpickering's suggestion on IRC this is to make the partial
module-graph more easily accessible for API clients which don't intend to
re-implementing depanal.

- - - - -
a0646db3 by Daniel Gröber at 2019-06-04T03:42:12Z
Improve targetContents code docs

- - - - -
c26461fc by Ömer Sinan Ağacan at 2019-06-04T03:42:15Z
Fix rewriting invalid shifts to errors

Fixes #16449.

5341edf3 removed a code in rewrite rules for bit shifts, which broke the
"silly shift guard", causing generating invalid bit shifts or heap
overflow in compile time while trying to evaluate those invalid bit
shifts.

The "guard" is explained in Note [Guarding against silly shifts] in
PrelRules.hs.

More specifically, this was the breaking change:

    --- a/compiler/prelude/PrelRules.hs
    +++ b/compiler/prelude/PrelRules.hs
    @@ -474,12 +474,11 @@ shiftRule shift_op
            ; case e1 of
                _ | shift_len == 0
                  -> return e1
    -             | shift_len < 0 || wordSizeInBits dflags < shift_len
    -             -> return (mkRuntimeErrorApp rUNTIME_ERROR_ID wordPrimTy
    -                                        ("Bad shift length" ++ show shift_len))

This patch reverts this change.

Two new tests added:

- T16449_1: The original reproducer in #16449. This was previously
  casing a heap overflow in compile time when CmmOpt tries to evaluate
  the large (invalid) bit shift in compile time, using `Integer` as the
  result type. Now it builds as expected. We now generate an error for
  the shift as expected.

- T16449_2: Tests code generator for large (invalid) bit shifts.

- - - - -
ed737292 by Ömer Sinan Ağacan at 2019-06-04T03:42:20Z
Fix arity type of coerced types in CoreArity

Previously if we had

    f |> co

where `f` had arity type `ABot N` and `co` had arity M and M < N,
`arityType` would return `ABot M` which is wrong, because `f` is only
known to diverge when applied to `N` args, as described in Note
[ArityType]:

    If at = ABot n, then (f x1..xn) definitely diverges. Partial
    applications to fewer than n args may *or may not* diverge.

This caused incorrect eta expansion in the simplifier, causing #16066.

We now return `ATop M` for the same expression so the simplifier can't
assume partial applications of `f |> co` is divergent.

A regression test T16066 is also added.

- - - - -
0b91a029 by Krzysztof Gogolewski at 2019-06-04T03:42:27Z
Handle hs-boot files in -Wmissing-home-modules (#16551)


(cherry picked from commit 43a43a3319d68c1692df6acdf283109cb5c030d8)
- - - - -
8a96ab44 by Zubin Duggal at 2019-06-04T03:42:33Z
Fix and enforce validation of header for .hie files

Implements #16686

automatically generate hieVersion from ghc version

- - - - -
921941ee by Zubin Duggal at 2019-06-04T03:42:33Z
Make header human readable

- - - - -
4542f25d by Alec Theriault at 2019-06-04T03:42:39Z
Bump Haddock submodule to 2.23 release

This commit of Haddock is (hopefully) going to be the one corresponding
to a Hackage release of Haddock 2.23.

- - - - -
f8d24178 by Michael Sloan at 2019-06-04T03:42:46Z
Have GHCi use object code for UnboxedTuples modules #15454

The idea is to automatically enable -fobject-code for modules that use
UnboxedTuples, along with all the modules they depend on. When looking
into how to solve this, I was pleased to find that there was already
highly similar logic for enabling code generation when -fno-code is
specified but TemplateHaskell is used.

The state before this patch was that if you used unboxed tuples then you
had to enable `-fobject-code` globally rather than on a per module
basis.

- - - - -
7258f41b by Michael Sloan at 2019-06-04T03:42:46Z
Add PlainPanic for throwing exceptions without depending on pprint

This commit splits out a subset of GhcException which do not depend on
pretty printing (SDoc), as a new datatype called
PlainGhcException. These exceptions can be caught as GhcException,
because 'fromException' will convert them.

The motivation for this change is that that the Panic module
transitively depends on many modules, primarily due to pretty printing
code.  It's on the order of about 130 modules.  This large set of
dependencies has a few implications:

1. To avoid cycles / use of boot files, these dependencies cannot
throw GhcException.

2. There are some utility modules that use UnboxedTuples and also use
`panic`. This means that when loading GHC into GHCi, about 130
additional modules would need to be compiled instead of
interpreted. Splitting the non-pprint exception throwing into a new
module resolves this issue. See #13101

(cherry picked from commit fe9034e9b4820214a8c703bd8a3146ce6eed37b8)

- - - - -
3be42032 by Michael Sloan at 2019-06-04T03:42:46Z
Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)

Also removes a couple unnecessary MagicHash pragmas

(cherry picked from commit 061276ea5d265eb3c23a3698f0a10f6a764ff4b4)

- - - - -
a675f498 by Michael Sloan at 2019-06-04T03:42:47Z
Extract out use of UnboxedTuples from GHCi.Leak

See #13101 + #15454 for motivation.  This change reduces the number of
modules that need to be compiled to object code when loading GHC into
GHCi.

(cherry picked from commit c01d5af31c8feb634fc3dffc84e6e7ece61ba190)

- - - - -
7af05bc4 by Michael Sloan at 2019-06-04T03:42:47Z
Use datatype for unboxed returns when loading ghc into ghci

See #13101 and #15454

(cherry picked from commit 64959e51bf17a9f991cc345476a40515e7b32d81)

- - - - -
bbdcc375 by Ben Gamari at 2019-06-04T21:59:48Z
testsuite: Mark concprog001 as fragile

Due to #16604.

- - - - -
32ae6b2a by Ben Gamari at 2019-06-04T22:00:59Z
Merge remote-tracking branch 'osa1/backport_t16066' into wip/ghc-8.8-merges

- - - - -
a91acd25 by Ben Gamari at 2019-06-04T22:01:54Z
Merge remote-tracking branch 'origin/cherry-pick-43a43a33' into wip/ghc-8.8-merges

- - - - -
d21c21fc by Ben Gamari at 2019-06-04T22:02:11Z
Merge remote-tracking branch 'osa1/port_16449_ghc_8_8' into wip/ghc-8.8-merges

- - - - -
86259c2d by Ben Gamari at 2019-06-04T22:03:03Z
Merge branch 'hie-backports-8.8' of https://gitlab.haskell.org/DanielG/ghc into wip/ghc-8.8-merges

- - - - -
5fccdfad by Ben Gamari at 2019-06-04T22:03:41Z
Merge branch 'wip/backport-ecc9366a0e0db107c286935130837b2222e2dd82' of https://gitlab.haskell.org/RyanGlScott/ghc into wip/ghc-8.8-merges

- - - - -
514e7bf8 by Ben Gamari at 2019-06-04T22:04:04Z
Merge branch 'cherry-pick-e172a6d1' of gitlab.haskell.org:ghc/ghc into wip/ghc-8.8-merges

- - - - -
0fb35ed4 by Ben Gamari at 2019-06-04T22:06:59Z
Merge branch 'wip/8-8-ghci' of gitlab.haskell.org:ghc/ghc into wip/ghc-8.8-merges

- - - - -
5c42df84 by Ben Gamari at 2019-06-04T22:07:26Z
Merge branch 'hiefile-header-8.8' of https://gitlab.haskell.org/wz1000/ghc into wip/ghc-8.8-merges

- - - - -
a598e25b by Ben Gamari at 2019-06-04T22:18:44Z
Add missing import

Missing from f8d24178f30b7837b35a9ea328bc6f520092ff08.

- - - - -
15752087 by Ben Gamari at 2019-06-04T22:54:55Z
Merge branch '8.8-haddock-release' of gitlab.haskell.org:harpocrates/ghc into wip/ghc-8.8-merges

- - - - -
686bd33a by Ben Gamari at 2019-06-04T22:59:24Z
Fix ghc-in-ghci

- - - - -
fe03067a by Ben Gamari at 2019-06-04T22:59:31Z
Haddock for hiefile-header

- - - - -
1134488b by Ben Gamari at 2019-06-05T00:31:38Z
Bump terminfo to 0.4.1.4

- - - - -
fdb07571 by Ben Gamari at 2019-06-05T00:34:27Z
Bump time submodule to 1.9.3

- - - - -
ff438786 by Ben Gamari at 2019-06-09T17:54:25Z
Bump Cabal submodule

- - - - -
983ada70 by Ben Gamari at 2019-06-09T17:54:25Z
Bump binary to 0.8.7.0

- - - - -


30 changed files:

- compiler/backpack/DriverBkp.hs
- compiler/basicTypes/UniqSupply.hs
- compiler/codeGen/StgCmmMonad.hs
- compiler/coreSyn/CoreArity.hs
- compiler/ghc.cabal.in
- compiler/ghci/ByteCodeLink.hs
- compiler/ghci/RtClosureInspect.hs
- compiler/hieFile/HieAst.hs
- compiler/hieFile/HieBin.hs
- compiler/hieFile/HieDebug.hs
- compiler/hieFile/HieTypes.hs
- compiler/iface/BinFingerprint.hs
- compiler/main/DriverPipeline.hs
- compiler/main/GhcMake.hs
- compiler/main/HeaderInfo.hs
- compiler/main/HscMain.hs
- compiler/main/HscTypes.hs
- compiler/main/InteractiveEval.hs
- compiler/nativeGen/AsmCodeGen.hs
- compiler/nativeGen/RegAlloc/Linear/State.hs
- compiler/prelude/PrelRules.hs
- compiler/utils/Binary.hs
- compiler/utils/FastString.hs
- compiler/utils/Panic.hs
- + compiler/utils/PlainPanic.hs
- compiler/utils/Pretty.hs
- compiler/utils/StringBuffer.hs
- compiler/utils/Util.hs
- docs/users_guide/8.8.1-notes.rst
- docs/users_guide/ghci.rst


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/605869c7b776ce6071a31ff447998b081e0354ed...983ada70a013c7642a751f6e41587ff95b57d0f8

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/605869c7b776ce6071a31ff447998b081e0354ed...983ada70a013c7642a751f6e41587ff95b57d0f8
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20190610/44071629/attachment-0001.html>

More information about the ghc-commits mailing list