GitLab

As discussed in #16331, the GHCI macro, defined through 'ghci' flags
in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
whether GHC is built with support for an internal interpreter, that runs in
the same process. It is however overloaded in a few places to mean
"there is an interpreter available", regardless of whether it's an internal
or external interpreter.

For the sake of clarity and with the hope of more easily being able to
build stage 1 GHCs with external interpreter support, this patch splits
the previous GHCI macro into 3 different ones:

- HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
- HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
- HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: hvr, simonpj, mpickering, rwbarton, carter

GHC Trac Issues: #15838

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

It shouldn't be needed these days, and those primops are "highly
deprecated" anyways.

This fits with my plans because it removes one bit of target-dependence
of the builtin primops, and this is the hardest part of GHC to make
multi-target.

CC @carter

There were actually two bugs fixed here:

1. candidateQTyVarsOfType needs to be careful that it does not
   try to zap metavariables from an outer scope as "naughty"
   quantification candidates. This commit adds a simple check
   to avoid doing so.

2. We weren't bumping the TcLevel in kcHsKindSig, which was used
   only for class method sigs. This mistake led to the acceptance
   of

     class C a where
       meth :: forall k. Proxy (a :: k) -> ()

   Note that k is *locally* quantified. This patch fixes the
   problem by using tcClassSigType, which correctly bumps the
   level. It's a bit inefficient because tcClassSigType does other
   work, too, but it would be tedious to repeat much of the code
   there with only a few changes. This version works well and is
   simple.

And, while updating comments, etc., I noticed that tcRnType was
missing a pushTcLevel, leading to #16767, which this patch also
fixes, by bumping the level. In the refactoring here, I also
use solveEqualities. This initially failed ghci/scripts/T15415,
but that was fixed by teaching solveEqualities to respect
-XPartialTypeSignatures.

This patch also cleans up some Notes around error generation that
came up in conversation.

Test case: typecheck/should_fail/T16517, ghci/scripts/T16767

Package DB directories with trailing separator (provided via
GHC_PACKAGE_PATH or via -package-db) resulted in incorrect calculation of
${pkgroot} substitution variable.  Keep the trailing separator while
resolving as directory or file, but remove it before dropping the last
path component with takeDirectory.

Closes #16360.

Previously log and exp were primitives yet log1p and expm1 were FFI
calls. Fix this non-uniformity.

[skip ci]

This should really be caught by the linters! (#16711)

When the canonicaliser rewrites evidence of a Wanted, it
should preserve the ShadowInfo (ctev_nosh) field.  That is,
a WDerive should rewrite to WDerive, and WOnly to WOnly.

Previously we were unconditionally making a WDeriv, thereby
rewriting WOnly to WDeriv.  This bit Nick Frisby (issue #16735)
in the context of his plugin, but we don't have a compact test
case.

The fix is simple, but does involve a bit more plumbing,
to pass the old ShadowInfo around, to use when building
the new Wanted.

ghc-pkg and ghc already both needed this. I figure it is better to
deduplicate, especially seeing that changes to one (FreeBSD CPP) didn't
make it to the other.

Additionally in !1090 I make ghc-pkg look up the settings file, which
makes it use the top dir a bit more widely. If that lands, any
difference in the way they find the top dir would be more noticable.

That change also means sharing more code between ghc and ghc-package
(namely the settings file parsing code), so I'd think it better to get
off the slipperly slope of duplicating code now.

`:info Coercible` now outputs the correct section number of the GHCi User's guide together with the secion title.

`:forward x` gives the correct syntax hint.

The `PmExprEq` business was a huge hack and was at the same time vastly
too powerful and not powerful enough to encode negative term equalities,
i.e. facts of the form "forall y. x ≁ Just y".

This patch introduces the concept of 'refutable shapes': What matters
for the pattern match checker is being able to encode knowledge of the
kind "x can no longer be the literal 5". We encode this knowledge in a
`PmRefutEnv`, mapping a set of newly introduced `PmAltCon`s (which are
just `PmLit`s at the moment) to each variable denoting above
inequalities.

So, say we have `x ≁ 42 ∈ refuts` in the term oracle context and
try to solve an equality like `x ~ 42`. The entry in the refutable
environment will immediately lead to a contradiction.

This machinery renders the whole `PmExprEq` and `ComplexEq` business
unnecessary, getting rid of a lot of (mostly dead) code.

See the Note [Refutable shapes] in TmOracle for a place to start.

Metric Decrease:
    T11195

[skip ci] Improve the documentation of the CNF primops. In this context, the term "size" is ambiguous and is now avoided. Additionally, the distinction between a CNF and the blocks that comprise it has been emphasize. The vocabulary has been made more consistent with the vocabulary in the C source for CNF.

This commit adds the `:instances` command to ghci following proosal
number 41.

This makes it possible to query which instances are available to a given
type.

The output of this command is all the possible instances with type
variables and constraints instantiated.

Use a better strategy for determining the offset applied to foreign function arguments that have an unlifted boxed type. We used to use the type of the argument. We now use the type of the foreign function. Add a test to confirm that the roundtrip conversion between an unlifted boxed type and Any is sound in the presence of a foreign function call.

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.

When running the test suite on a GHC built with the `quick` build
flavour, `-fghci-leak-check` noticed some space leaks. Careful
investigation led to `Linker.dynLoadObjs` being the culprit.
Pattern-matching on `PeristentLinkerState` and a dash of `$!` were
sufficient to fix the issue. (ht to mpickering for his suggestions,
which were crucial to discovering a fix)

Fixes #16708.

This replaces a panic observed in #16702 with a simple error message
stating that nested `forall`s simply aren't allowed in the type
signature of a `foreign import` (at least, not at present).

Fixes #16702.

Implements #16686

The files version is automatically generated from the current GHC
version in the same manner as normal interface files.

This means that clients can first read the version and then decide how
to read the rest of the file.

`mkBootModDetailsTc`, which creates a special `ModDetails` when
`-fno-code` is enabled, was not properly filling in the `COMPLETE`
signatures from the `TcGblEnv`, resulting in incorrect pattern-match
coverage warnings. Easily fixed.

Fixes #16682.

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.

These were meant to be added in !214 but for some reason wasn't included
in the patch.

Update Haddock submodule for new Types.hs hyperlinker output

When ghc was built for powerpc32 built failed as:

It's a fallout of commit 3f46cffc
("PPC NCG: Refactor stack allocation code") where
word size used to be
    II32/II64
and changed to
    II8/panic "no width for given number of bytes"
    widthFromBytes ((platformWordSize platform) `quot` 8)

The change restores initial behaviour by removing extra division.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

On powerpc32 64-bit comparison code generated dangling
target labels. This caused ghc build failure as:

    $ ./configure --target=powerpc-unknown-linux-gnu && make
    ...
    SCCs aren't in reverse dependent order
    bad blockId n3U

This happened because condIntCode' in PPC codegen generated
label name but did not place the label into `cmp_lo` code block.

The change adds the `cmp_lo` label into the case of negative
comparison.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

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.

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.

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

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.

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

After the previous commit, `Settings` is just a thin wrapper around
other groups of settings. While `Settings` is used by GHC-the-executable
to initalize `DynFlags`, in principle another consumer of
GHC-the-library could initialize `DynFlags` a different way. It
therefore doesn't make sense for `DynFlags` itself (library code) to
separate the settings that typically come from `Settings` from the
settings that typically don't.