GitLab

Reviewers: hvr, goldfire, austin, RyanGlScott, bgamari

Reviewed By: RyanGlScott, bgamari

Subscribers: RyanGlScott, thomie

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

Summary:
Import libraries are files ending in `.dll.a` and `.lib` depending on which
compiler creates them (GCC, vs MSVC).

Import Libraries are standard `archive` files that contain object files.
These object files can have two different formats:

1) The normal COFF Object format for object files
    (contains all ascii data and very little program code, so do not
     try to execute.)
2) "short import" format which just contains a symbol name and
   the dll in which the symbol can be found.

Import Libraries are useful for two things:

1) Allowing applications that don't support dynamic linking to
   link against the import lib (non-short format) which then
   makes calls into the DLL by loading it at runtime.

2) Allow linking of mutually recursive dlls. if `A.DLL` requires
   `B.DLL` and vice versa, import libs can be used to break the cycle
   as they can be created from the expected exports of the DLLs.

A side effect of having these two capabilities is that Import libs are often
used to hide specific versions of DLLs behind a non-versioned import lib.

e.g. GCC_S.a (non-conventional import lib) will point to the correct
`libGCC` DLL. With this support Windows Haskell files can now just link
to `-lGCC_S` and not have to worry about what the actual name of libGCC is.

Also third party libraries such as `icuuc` use import libs to forward to
versioned DLLs. e.g. `icuuc.lib` points to `icuuc51.dll` etc.

Test Plan:
./validate

Two new tests added T11072gcc T11072msvc

Two binary files have been added to the test folder because the "short"
import library format doesn't seem to be creatable via `dlltool`
and requires Microsoft's `lib.exe`.

Reviewers: bgamari, RyanGlScott, erikd, goldfire, austin, hvr

Reviewed By: RyanGlScott, erikd

Subscribers: thomie

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

GHC Trac Issues: #11072

This patch tides up the structure, simplifying FlattenTvResult.

It also replaces a use of zonkTcType (which I hated) with
coercionKind, in that same function.  Happily, the result is
little faster, maybe even a percentage point or two, which is
a lot for a compiler.

This also removes the line
   || not (map binderVisibility bndrs1 == map binderVisibility bndrs2)
from TcCanonical.can_eq_nc', in the ForAllTy/ForAllTy case.

Why? Becuase I can't see why binder-visiblity should matter, and
when we use coercionKind instead of zonkTcType in flattenTyVar,
this case pops up and rejects a program that should pass.  I did
discuss this with Richard.

Test Plan: Validate

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #11827

Test Plan: Validate

Reviewers: goldfire, austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #11824

Fixes Trac #11793.  Nothing deep here.

in order to have precise used-once information in the exported
strictness signatures, as well as precise used-once information on
thunks. This avoids the bad effects of #11731.

The subsequent worker-wrapper pass is responsible for removing the
demand environment part of the strictness signature. It does not run
after the final demand analyzer pass, so remove this also in CoreTidy.

The subsequent worker-wrapper pass is also responsible for removing
used-once-information from the demands and strictness signatures, as
these might not be preserved by the simplifier. This is _not_ done by
CoreTidy, because we _do_ want this information, as produced by the last
round of the demand analyzer, to be available to the code generator.

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

DsMeta curiously omitted quantified tyvars in certain circumstances.
This patch means it doesn't.

Test case: th/T11797

Previously, I had forgotten to omit variables already in scope
from the TypeInType CUSK check. Simple enough to fix.

Test case: typecheck/should_compile/T11811

While the deriving machinery always unifies the kind of the typeclass
argument with the kind of the datatype, this proves not to be sufficient
to produce well kinded instances for some poly-kinded datatypes. For
example:

```
newtype Compose (f :: k2 -> *) (g :: k1 -> k2) (a :: k1)
  = Compose (f (g a)) deriving Functor
```

would fail because only `k1` would get unified with `*`, causing the
following
ill kinded instance to be generated:

```
instance (Functor (f :: k2 -> *), Functor (g :: * -> k2)) =>
  Functor (Compose f g) where ...
```

To prevent this, we need to take the subtypes and unify their kinds with
`* -> *`.

Fixes #10524 for good.

Test Plan: ./validate

Reviewers: simonpj, hvr, austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #10524, #10561

Previously, all kind arguments were being reified, which would cause
something like this:

```
type Id a = a
data Proxy (a :: Id k) = Proxy
```

to output

```
data Proxy (a :: Id * k) = Proxy
```

when `Proxy`'s `Info` is reified. The fix is simple: simply call
`filterOutInvisibleTypes` on the kind arguments of a kind synonym
application.

Fixes #11463.

Test Plan: ./validate

Reviewers: austin, bgamari, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #11463

Now we check whether a closed type family's equation is headed with
the correct type before we kind-check the equation.

Also, instead of "expected only no parameters" we now generate the
message "expected no parameters".

Fixes #11623.

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: simonpj, goldfire, thomie

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

GHC Trac Issues: #11623

The Runtime Linker is currently eagerly loading all object files on all
platforms which do not use the system linker for `GHCi`.

The problem with this approach is that it requires all symbols to be
found.  Even those of functions never used/called. This makes the number
of libraries required to link things like `mingwex` quite high.

To work around this the `rts` was relying on a trick. It itself was
compiled with `MingW64-w`'s `GCC`. So it was already linked against
`mingwex`.  As such, it re-exported the symbols from itself.

While this worked it made it impossible to link against `mingwex` in
user libraries. And with this means no `C99` code could ever run in
`GHCi` on Windows without having the required symbols re-exported from
the rts.

Consequently this rules out a large number of packages on Windows.
SDL2, HMatrix etc.

After talking with @rwbarton I have taken the approach of loading entire
object files when a symbol is needed instead of doing the dependency
tracking on a per symbol basis. This is a lot less fragile and a lot
less complicated to implement.

The changes come down to the following steps:

1) modify the linker to and introduce a new state for ObjectCode:
   `Needed`.  A Needed object is one that is required for the linking to
   succeed.  The initial set consists of all Object files passed as
   arguments to the link.

2) Change `ObjectCode`'s to be indexed but not initialized or resolved.
   This means we know where we would load the symbols,
   but haven't actually done so.

3) Mark any `ObjectCode` belonging to `.o` passed as argument
   as required: ObjectState `NEEDED`.

4) During `Resolve` object calls, mark all `ObjectCode`
   containing the required symbols as `NEEDED`

5) During `lookupSymbol` lookups, (which is called from `linkExpr`
   and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded
   `ObjectCode` then load the `ObjectCode` on demand and return the
   address of the symbol. Otherwise produce an unresolved symbols error
   as expected.

6) On `unloadObj` we then change the state of the object and remove
   it's symbols from the `reqSymHash` table so it can be reloaded.

This change affects all platforms and OSes which use the runtime linker.
It seems there are no real perf tests for `GHCi`, but performance
shouldn't be impacted much. We gain a lot of time not loading all `obj`
files, and we lose some time in `lookupSymbol` when we're finding
sections that have to be loaded. The actual finding itself is O(1)
(Assuming the hashtnl is perfect)

It also consumes slighly more memory as instead of storing just the
address of a symbol I also store some other information, like if the
symbol is weak or not.

This change will break any packages relying on renamed POSIX functions
that were re-named and re-exported by the rts. Any packages following
the proper naming for functions as found on MSDN will work fine.

Test Plan: ./validate on all platforms which use the Runtime linker.

Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr

Reviewed By: erikd

Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar,
             rwbarton, #ghc_windows_task_force

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

GHC Trac Issues: #11223

Previously, deriving `Generic(1)` bailed out when attempting to
instantiate visible type parameters (#5939), but this instantiation
check was quite fragile and doesn't interact well with `-XTypeInType`.
It has been decided that `Generic(1)` shouldn't be subjected to this
check anyway, so it has been removed, and `gen_Generic_binds`'s
machinery has been updated to substitute the type variables in a
generated `Rep`/`Rep1` instance with the user-supplied type arguments.

In addition, this also refactors `Condition` in `TcDeriv` a bit. Namely,
since we no longer need `tc_args` to check any conditions, the `[Type]`
component of `Condition` has been removed.

Fixes #11732.

Test Plan: ./validate

Reviewers: goldfire, kosmikus, simonpj, bgamari, austin

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #5939, #11732

When the typechecker generates the error message for an out-of-scope
variable, it now uses the GlobalRdrEnv with respect to which the
variable is unbound, not the GlobalRdrEnv which is available at the time
the error is reported.  Doing so ensures we do not provide suggestions
which themselves are out-of-scope (because they are bound in a later
inter-splice group).

Nonetheless, we do note in the error message if an unambiguous, exact
match to the out-of-scope variable is found in a later inter-splice
group, and we specify where that match is not in scope.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #11680

The commit 28f951ed introduced the
`-fmax-pmcheck-iterations` flag and set the default limit to 1e7
iterations.

However, this value is still high enough that it can result GHC to
exhibit memory spikes beyond 1 GiB of RAM usage (heap profile showed
several `(:)`s, as well as `THUNK_2_0`, and `PmCon` during the memory
spikes)

A value of 2e6 seems to be a safer upper bound which still manages to
let the checker not run into the limit in most cases.

Test Plan: Validate, try building a few Hackage packages

Reviewers: austin, gkaracha, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Record selectors of data types spliced in with Template Haskell are not
renamer-resolved correctly in GHC HEAD. The culprit is
`newRecordSelector` which violates notes `Note [Binders in Template
Haskell] in Convert.hs` and `Note [Looking up Exact RdrNames] in
RnEnv.hs`. This commit fixes `newRecordSelector` accordingly.

Test Plan: ./validate

Reviewers: thomie, mpickering, bgamari, austin, simonpj, goldfire

Reviewed By: goldfire

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

GHC Trac Issues: #11809

Since recent changes to CSE, the previous definition were no longer CSEd
with thenIO, which resulted in extra steps in the simplifier and hence
slightly larger compile times. See ticket:11781#comment:7.

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

This reverts commit 06b7ce21.

(cherry picked from commit 6d36d8e1)

to what phabricator found; not sure why my local validation yielded
different numbers.

Summary:
Till now tct_closed determined whether the type of a binding is closed.
With this patch tct_closed indicates whether the binding is closed.

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: mboes, thomie, simonpj

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

GHC Trac Issues: #11698

as suggested in ticket:11770#comment:1. This code was buggy
(#11770), and the occurrence analyzer does the same job anyways.

This also elaborates the notes in the occurrence analyzer accordingly.

Previously, the worker/wrapper code would go through lengths to transfer
the oneShot annotations from the original function to both the worker
and the wrapper. We now simply transfer the demand on the worker, and
let the subsequent occurrence analyzer push this onto the lambda
binders.

This also requires the occurrence analyzer to do this more reliably.
Previously, it would not hand out OneShot annotatoins to things that
would not `certainly_inline` (and it might not have mattered, as the
Demand Analysis might have handed out the annotations). Now we hand out
one-shot annotations unconditionally.

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

Triggered by an observation by Joachim, Simon felt the urge to clean up
the CSE code a bit. This is the result.

(Code by Simon, commit message and other leg-work by Joachim)

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

as they (especially their id info with absence information) clutter the
output too much. They come back with debug_on.

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

It's been quite a while since this has happened for some of our tests.

Shifts by amounts greater-than-or-equal-to the word size are undefined.

This fixes a bug where warnings actually controlled by

- `Opt_WarnUnusedMatches`
- `Opt_WarnUnusedTypePatterns`
- `Opt_WarnUnusedTopBinds`

were incorrectly reported as being controlled by
`Opt_WarnUnusedLocalBinds` as well

This bug was introduced in bb5afd3c
while implementing #10752

Test Plan: ./validate still running -- testsuite output wiggles expected

Reviewers: barrucadu, quchen, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

We originally wanted CallStacks to be opt-in, but dealing with let
binders complicated things, forcing us to infer CallStacks. It turns
out that the inference is actually unnecessary though, we can let the
wanted CallStacks bubble up to the outer context by refusing to
quantify over them. Eventually they'll be solved from a given CallStack
or defaulted to the empty CallStack if they reach the top.

So this patch prevents GHC from quantifying over CallStacks, getting us
back to the original plan. There's a small ugliness to do with
PartialTypeSignatures, if the partial theta contains a CallStack
constraint, we *do* want to quantify over the CallStack; the user asked
us to!

Note that this means that

  foo :: _ => CallStack
  foo = getCallStack callStack

will be an *empty* CallStack, since we won't infer a CallStack for the
hole in the theta. I think this is the right move though, since we want
CallStacks to be opt-in. One can always write

  foo :: (HasCallStack, _) => CallStack
  foo = getCallStack callStack

to get the CallStack and still have GHC infer the rest of the theta.

Test Plan: ./validate

Reviewers: goldfire, simonpj, austin, hvr, bgamari

Reviewed By: simonpj, bgamari

Subscribers: bitemyapp, thomie

Projects: #ghc

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

GHC Trac Issues: #11573

This just adds the Prox stuff from the Description in Trac #11376
to the test case,

The class stuff seems weird becuase the type is ambiguous

Stable pointers can now be safely dereferenced while the stable pointer
table is simultaneously being enlarged.

Test Plan: ./validate

Reviewers: ezyang, austin, bgamari, simonmar

Subscribers: carter, thomie

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

GHC Trac Issues: #10296

See Trac #11376 and
 Note [Deeply instantiate in :type] in TcRnDriver

Sadly this showed up one new problem (Trac #11786) and one opportunity
(Trac #11787), so test T11549 is now marked expect-broken on these two.

Add the function `pprPatSynType :: PatSyn -> SDoc` for printing pattern
synonym types, and remove the ambiguous `patSynType` function. Also,
the types in a `PatSyn` are now tidy.

Haddock submodule updated to reflect the removal of `patSynType` by
mpickering.

Fixes: #11213.

Reviewers: goldfire, simonpj, austin, mpickering, bgamari

Reviewed By: simonpj, mpickering

Subscribers: bollmann, simonpj, thomie

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

GHC Trac Issues: #11213

This reverts commit 28fe0eea due to
various regressions. I’m not sure why my local
./validate --slow
run did not catch this, though.

as suggested in ticket:11770#comment:1. This code was buggy (#11770),
and the occurrence analyzer does the same job anyways.

This also elaborates the notes in the occurrence analyzer accordingly.

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

The result of a series of patches on type-error messages for
pattern synonyms had become a bit baroque. This tidies it up
a bit.  Still not fantastic, but better.

This turns `Any` into a standard wired-in type family defined in
`GHC.Types`, instead its current incarnation as a magical creature
provided by the `GHC.Prim`.  Also kill `AnyK`.

See #10886.

Test Plan: Validate

Reviewers: simonpj, goldfire, austin, hvr

Reviewed By: simonpj

Subscribers: goldfire, thomie

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

GHC Trac Issues: #10886

Test Plan: validate

Reviewers: thomie, austin, bgamari

Reviewed By: bgamari

Subscribers: hvr

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

GHC Trac Issues: #11763