GitLab

Fixes #10267. Typed holes in typed Template Haskell currently don't work.
See #10945 and #10946.

This implements DuplicateRecordFields, the first part of the
OverloadedRecordFields extension, as described at
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields

This includes fairly wide-ranging changes in order to allow multiple
records within the same module to use the same field names.  Note that
it does *not* allow record selector functions to be used if they are
ambiguous, and it does not have any form of type-based disambiguation
for selectors (but it does for updates). Subsequent parts will make
overloading selectors possible using orthogonal extensions, as
described on the wiki pages.  This part touches quite a lot of the
codebase, and requires changes to several GHC API datatypes in order
to distinguish between field labels (which may be overloaded) and
selector function names (which are always unique).

The Haddock submodule has been adapted to compile with the GHC API
changes, but it will need further work to properly support modules
that use the DuplicateRecordFields extension.

Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
will be extended once the other parts are implemented.

Reviewers: goldfire, bgamari, simonpj, austin

Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
goldfire

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

On 64-bit ELF we need to link object files into the low 2GB due to the
small memory model.  Previously we would map the entire object file
using MAP_32BIT, but the object file can consist of 75% or more
symbols, which only need to be present during linking, so this is
wasteful.  In our particular application, we're already running out of
space here.

This patch changes the way we load object files on ELF platforms so
that the object is first mapped above the 2GB boundary, parsed, and
then the important sections are re-mapped into the low 2GB area.

Test Plan:
validate
(also needs testing on OS X & Windows, preferably 32 & 64 bit)

Reviewers: Phyx, trommler, bgamari, austin

Subscribers: hsyl20, thomie, bgamari

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

Comes with Haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This commit contains a Cabal submodule update which unifies installed
package IDs and package keys under a single notion, a Component ID.
We update GHC to keep follow this unification.  However, this commit
does NOT rename installed package ID to component ID and package key to
unit ID; the plan is to do that in a companion commit.

    - Compiler info now has "Requires unified installed package IDs"

    - 'exposed' is now expected to contain unit keys, not IPIDs.

    - Shadowing is no more.  We now just have a very simple strategy
      to deal with duplicate unit keys in combined package databases:
      if their ABIs are the same, use the latest one; otherwise error.
      Package databases maintain the invariant that there can only
      be one entry of a unit ID.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari, hvr, goldfire

Subscribers: thomie

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

GHC Trac Issues: #10714

Currently, GHC's warning generation code is assuming that a name (`RdrName`)
can be imported at most once. This is a correct assumption, because 1) it's OK
to import same names as long as we don't use any of them 2) when we use one of
them, GHC generates an error because it doesn't disambiguate it automatically.

But apparently the story is different with typeclass methods. If I import two
methods with same names, it's OK to use them in typeclass instance
declarations, because the context specifies which one to use. For example, this
is OK (where modules A and B define typeclasses A and B, both with a function
has),

    import A
    import B

    data Blah = Blah

    instance A Blah where
      has = Blah

    instance B Blah where
      has = Blah

But GHC's warning generator is not taking this into account, and so if I change
import list of this program to:

    import A (A (has))
    import B (B (has))

GHC is printing these warnings:

    Main.hs:5:1: Warning:
        The import of ‘A.has’ from module ‘A’ is redundant

    Main.hs:6:1: Warning:
        The import of ‘B.has’ from module ‘B’ is redundant

Why? Because warning generation code is _silently_ ignoring multiple symbols
with same names.

With this patch, GHC takes this into account. If there's only one name, then
this patch reduces to the previous version, that is, it works exactly the same
as current GHC (thanks goes to @quchen for realizing this).

Reviewed By: austin

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

GHC Trac Issues: #10890

Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
freak out if using a `Data` instance that produces a `Constr` (by means of
`toConstr`) using a function name instead of a data constructor name. While
such `Data` instances are somewhat questionable, they are nevertheless present
in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
aware of their existence.

In order to properly distinguish strings which represent variables (as opposed
to data constructors), it was necessary to move functionality from `Lexeme` (in
`ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
`bin-package-db`).

Reviewed By: goldfire, thomie

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

GHC Trac Issues: #10796

This fallout was caused by f8fbf385 (see #10935), and looks easy
enough, but admittedly I just tried patching the output, so we're doing it
live.
Signed-off-by: Austin Seipp <austin@well-typed.com>

HERMIT users depend on RULES to specify equational properties. 7.10.2
performed both inlining and simplification in both sides of the rules, meaning
they can't really be used for this. This breaks most HERMIT use cases.  A
separate commit already disabled this for the LHS of rules. This does so for
the RHS.

See Trac #10829 for nofib results.

Reviewed By: austin, bgamari, simonpj

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

GHC Trac Issues: #10829

This patch is driven by Trac #10935, and reinstates the
-fwarn-monomorphism-restriction warning.  It was first lost in 2010:
d2ce0f52 "Super-monster patch implementing the new typechecker -- at
last"

I think the existing documentation is accurate; it is not even
turned on by -Wall.

I added one test.

Summary: Test included.

Test Plan: Run test T10870.hs on X86/X86_64/Arm/Arm64 etc

Reviewers: bgamari, nomeata, austin

Subscribers: thomie

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

GHC Trac Issues: #10870

Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc
to pass -L to all components by using -B instead. These two fix
shortnames linking on windows.

re-enabled tests: ghcilink003, ghcilink006 and T3333
Added two tests: load_short_name and enabled T1407 on windows.

Reviewed By: thomie, bgamari

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

GHC Trac Issues: #9878, #1407, #1883, #5289

Summary:
Instead of doing these warnings at MkIface time, we do them
when we create the instances/rules in the typechecker/desugarer.

Emitting warnings for auto-generated instances was a pain
(since the specialization monad doesn't have the capacity
to emit warnings) so instead I just deprecated -fwarn-auto-orphans.
Auto rule orphans are pretty harmless anyway: they don't cause
interface files to be eagerly loaded in.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie

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

Among doing other things, Phab:D201 (bc2289e1)
tried to improve the error messages thrown by the parser. For example a missing
else clause now prints "parse error in if statement: else clause empty" instead
of "parse error (possibly incorrect indentation or mismatched brackets)".

Some error messages got much worse however (see tests), and the result seems to
be a net negative. Although not entirely satisfactory, this commits therefore
reverts those parser changes.

Reviewed By: austin

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

GHC Trac Issues: #10498

For example

```
pattern head `Cons` tail = head : tail
```

Reviewed By: goldfire, austin

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

GHC Trac Issues: #10747

Improved error messages are only printed when the old message would be
"No instance for...", since they're not as helpful for "Could not deduce..."

No special test case as error messages are tested by other tests already.
Signed-off-by: David Kraeutmann <kane@kane.cx>

Reviewed By: austin, goldfire

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

GHC Trac Issues: #10733

A missing 'closeOverKinds' triggered Trac #10934.
Happily the fix is simple.

Merge to 7.10.3

Summary:
We had a duplicate copy of the code for --make and for -c
which was a pain.  The call graph looked something like this:

    compileOne -> genericHscCompileGetFrontendResult -> genericHscFrontend
                                   hscCompileOneShot ---^

with genericHscCompileGetFrontendResult and hscCompileOneShot
duplicating logic for deciding whether or not recompilation
was needed.

This patchset fixes it, so now everything goes through this call-chain:

    compileOne (--make entry point)
        Calls hscIncrementCompile, invokes the pipeline to do codegen
        and sets up linkables.
    hscIncrementalCompile (-c entry point)
        Calls hscIncrementalFrontend, and then simplifying,
        desugaring, and writing out the interface.
    hscIncrementalFrontend
        Performs recompilation avoidance, if recompilation needed,
        does parses typechecking.

I also cleaned up some of the MergeBoot nonsense by introducing
a FrontendResult type.

NB: this BREAKS #8101 again, because I can't unconditionally desugar
due to Haddock barfing on lint, see #10600Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, bgamari, simonmar, austin

Subscribers: thomie

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

Reviewed by: kgardas

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

It should be possible to run the testsuite with older versions of GHC.

Reviewed by: austin

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

The Windows Linker has 3 main parts that this patch changes.

1) Identification and classification of sections
2) Adding of symbols to the symbols tables
3) Reallocation of sections

1.
Previously section identification used to be done on a whitelisted
basis. It was also exclusively being done based on the names of the
sections. This meant that there was a bit of a cat and mouse game
between `GCC` and `GHC`. Every time `GCC` added new sections there was a
good chance `GHC` would break. Luckily this hasn't happened much in the
past because the `GCC` versions `GHC` used were largely unchanged.

The new code instead treats all new section as `CODE` or `DATA`
sections, and changes the classifications based on the `Characteristics`
flag in the PE header. By doing so we no longer have the fragility of
changing section names. The one exception to this is the `.ctors`
section, which has no differentiating flag in the PE header, but we know
we need to treat it as initialization data.

The check to see if the sections are aligned by `4` has been removed.
The reason is that debug sections often time are `1 aligned` but do have
relocation symbols. In order to support relocations of `.debug` sections
this check needs to be gone. Crucially this assumption doesn't seem to
be in the rest of the code. We only check if there are at least 4 bytes
to realign further down the road.

2.
The second loop is iterating of all the symbols in the file and trying
to add them to the symbols table. Because the classification of the
sections we did previously are (currently) not available in this phase
we still have to exclude the sections by hand. If they don't we will
load in symbols from sections we've explicitly ignored the in # 1. This
whole part should rewritten to avoid this. But didn't want to do it in
this commit.

3.
Finally the sections are relocated. But for some reason the PE files
contain a Linux relocation constant in them `0x0011` This constant as
far as I can tell does not come from GHC (or I couldn't find where it's
being set). I believe this is probably a bug in GAS. But because the
constant is in the output we have to handle it. I am thus mapping it to
the constant I think it should be `0x0003`.

Finally, static linking *should* work, but won't. At least not if you
want to statically link `libgcc` with exceptions support. Doing so would
require you to link `libgcc` and `libstd++` but also `libmingwex`. The
problem is that `libmingwex` also defines a lot of symbols that the RTS
automatically injects into the symbol table. Presumably because they're
symbols that it needs. like `coshf`. The these symbols are not in a
section that is declared with weak symbols support. So if we ever want
to get this working, we should either a) Ask mingw to declare the
section as such, or b) treat all a imported symbols as being weak.
Though this doesn't seem like it's a good idea..

Test Plan:
Running ./validate for both x86 and x86_64

Also running the specific test case for #10672

make TESTS="T10672_x86 T10672_x64"

Reviewed By: ezyang, thomie, austin

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

GHC Trac Issues: #9907, #10672, #10563

This started intermittently failing as a result of D1239.
I suspect this was just the straw that broke the camel's back however.

Summary:
Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in
associated type family defaults when deriving a class which contained
them.

In order to fix this properly, `tcATDefault` needed to be used from
`TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved
from `TcInstDcls` to `TcClsDcl`.

Fixes #10361.

Test Plan: ./validate

Reviewers: kosmikus, dreixel, bgamari, austin, simonpj

Subscribers: thomie

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

GHC Trac Issues: #10361

This warning was implemented via
abb3a9fa for addressing #7881. The
bounded H2010 integral types were handled, but the `Integer` type was
missed for the enumeration warning.

Fixes #10929

Test Plan: reused T7881 testcase

Reviewers: thomie, bgamari, austin

Reviewed By: thomie, bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #10929

This adds a data family (`URec`) and six data family instances (`UAddr`,
`UChar`, `UDouble`, `UFloat`, `UInt`, and `UWord`) which a `deriving
Generic(1)` clause will generate if it sees `Addr#`, `Char#`, `Double#`,
`Float#`, `Int#`, or `Word#`, respectively. The programmer can then
provide instances for these data family instances to provide custom
implementations for unboxed types, similar to how derived `Eq`, `Ord`,
and `Show` instances currently special-case unboxed types.

Fixes #10868.

Test Plan: ./validate

Reviewers: goldfire, dreixel, bgamari, austin, hvr, kosmikus

Reviewed By: dreixel, kosmikus

Subscribers: simonpj, thomie

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

GHC Trac Issues: #10868

Test Plan: ./validate

Reviewers: thomie, austin, bgamari

Reviewed By: bgamari

Subscribers: #ghc_windows_task_force

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

The Windows preprocessor code calls `runInteractiveProcess` but does
not check if an exception is thrown.
`runInteractiveProcess` calls `CreateProcess` which when given a format
the system loader does not know about
will throw an exception. This is what makes #9399 fail.

Ultimately we should not use any `CreateProcess` based calls but
instead `ShellExecuteEx` as  this would allow
us to run applications that the shell knows about instead of just the
loader. More details on #365.

This patch removes `PhaseFailed` and throws `ProgramError` instead.
`PhaseFailed` was largely unneeded since it never gave
very useful information aside from the `errorcode` which was almost
always `1`. `IOErrors` have also been eliminated and `GhcExceptions`
thrown in their place wherever possible.

Updates haddock submodule.

Test Plan:
`./validate` to make sure anything didn't break and
`make TESTS="T365"` to test that an error is now properly thrown

Reviewers: austin, thomie, bgamari

Reviewed By: thomie, bgamari

Subscribers: #ghc_windows_task_force

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

GHC Trac Issues: #365

Here we fix a few mis-optimizations that could occur in code with
floating point comparisons with -0.0. These issues arose from our
insistence on rewriting equalities into case analyses and the
simplifier's ignorance of floating-point semantics.

For instance, in Trac #10215 (and the similar issue Trac #9238) we
turned `ds == 0.0` into a case analysis,

```
case ds of
    __DEFAULT -> ...
    0.0 -> ...
```

Where the second alternative matches where `ds` is +0.0 and *also* -0.0.
However, the simplifier doesn't realize this and will introduce a local
inlining of `ds = -- +0.0` as it believes this is the only
value that matches this pattern.

Instead of teaching the simplifier about floating-point semantics
we simply prohibit case analysis on floating-point scrutinees and keep
this logic in the comparison primops, where it belongs.

We do several things here,

 - Add test cases from relevant tickets
 - Clean up a bit of documentation
 - Desugar literal matches against floats into applications of the
   appropriate equality primitive instead of case analysis
 - Add a CoreLint to ensure we don't pattern match on floats in Core

Test Plan: validate with included testcases

Reviewers: goldfire, simonpj, austin

Subscribers: thomie

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

GHC Trac Issues: #10215, #9238

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

As reported in Trac #10891, Template Haskell's `reify` was not
generating Decls for associated types. This patch fixes that.

Note that even though `reifyTyCon` function used in this patch returns
some type instances, I'm ignoring that.

Here's an example of how associated types are encoded with this patch:

(Simplified representation)

    class C a where
      type F a :: *

    -->

    OpenTypeFamilyD "F" ["a"]

With default type instances:

    class C a where
      type F a :: *
      type F a = a

    -->

    OpenTypeFamilyD "F" ["a"]
    TySynInstD "F" (TySynEqn [VarT "a"] "a")

Test Plan:
This patch was already reviewed and even merged. The patch is later
reverted because apparently it broke the build some time between the
validation of this patch and merge. Creating this new ticket to fix the
validation.

Reviewers: goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10891

and not the system locale, which might be something else. This fixes
bug #10907. A test is added, but less useful than it could be until
task #10909 is done.

Differential Revision: D1274

Summary:
DeriveGeneric generates some data types (for data type constructors and for
selectors of those constructors) and instances for those types. This patch
changes name generation for these new types to make it working with data types
with same names imported from different modules and with data types with same
names imported from same modules(using module imports).

Bonus content:

- Some refactoring in `TcGenGenerics.metaTyConsToDerivStuff` to remove some
  redundant partial function applications and to remove a duplicated function.
- Remove some unused names from `OccName`. (those were used for an old
  implementation of `DeriveGeneric`)

Reviewers: kosmikus, simonpj, dreixel, ezyang, bgamari, austin

Reviewed By: bgamari, austin

Subscribers: ezyang, thomie

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

GHC Trac Issues: #10487