1. 16 Oct, 2015 2 commits
    • Jan Stolarek's avatar
      Add typed holes support in Template Haskell. · 75492e74
      Jan Stolarek authored
      Fixes #10267. Typed holes in typed Template Haskell currently don't work.
      See #10945 and #10946.
      75492e74
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      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
      b1884b0e
  2. 15 Oct, 2015 3 commits
    • Simon Marlow's avatar
      ELF/x86_64: map object file sections separately into the low 2GB · 04e83666
      Simon Marlow authored
      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
      04e83666
    • Edward Z. Yang's avatar
      Rename package key to unit ID, and installed package ID to component ID. · b92a51f5
      Edward Z. Yang authored
      Comes with Haddock submodule update.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b92a51f5
    • Edward Z. Yang's avatar
      Update Cabal to HEAD, IPID renamed to Component ID. · 5b0191f7
      Edward Z. Yang authored
      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: default avatarEdward 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
      5b0191f7
  3. 13 Oct, 2015 4 commits
    • Ömer Sinan Ağacan's avatar
      Fix incorrect import warnings when methods with identical names are imported · 1818b48e
      Ömer Sinan Ağacan authored
      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
      1818b48e
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      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
      d2f9972a
    • Austin Seipp's avatar
      testsuite: attempt fixing T10935 output · 330ba6ad
      Austin Seipp authored
      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: default avatarAustin Seipp <austin@well-typed.com>
      330ba6ad
    • afarmer's avatar
      Don't inline/apply other rules when simplifying a rule RHS. · dcc34287
      afarmer authored
      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
      dcc34287
  4. 12 Oct, 2015 3 commits
  5. 10 Oct, 2015 2 commits
  6. 08 Oct, 2015 5 commits
  7. 06 Oct, 2015 2 commits
    • Simon Peyton Jones's avatar
      Fix kind-var abstraction in SimplUtils.abstractFloats · 0e169a8b
      Simon Peyton Jones authored
      A missing 'closeOverKinds' triggered Trac #10934.
      Happily the fix is simple.
      
      Merge to 7.10.3
      0e169a8b
    • Edward Z. Yang's avatar
      Deduplicate one-shot/make compile paths. · 427f8a15
      Edward Z. Yang authored
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, simonmar, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1302
      427f8a15
  8. 05 Oct, 2015 2 commits
  9. 04 Oct, 2015 1 commit
  10. 03 Oct, 2015 8 commits
    • Tamar Christina's avatar
      Make Windows linker more robust to unknown sections · 620fc6f9
      Tamar Christina authored
      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
      620fc6f9
    • Ben Gamari's avatar
      testsuite: Bump up haddock.base expected allocations · d2fb5328
      Ben Gamari authored
      This started intermittently failing as a result of D1239.
      I suspect this was just the straw that broke the camel's back however.
      d2fb5328
    • Ryan Scott's avatar
      Fill in associated type defaults with DeriveAnyClass · 2f74be9c
      Ryan Scott authored
      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
      2f74be9c
    • Herbert Valerio Riedel's avatar
      Enable `Enumeration is empty` warnings for `Integer` · 0eb8fcd9
      Herbert Valerio Riedel authored
      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
      0eb8fcd9
    • Ryan Scott's avatar
      Make GHC generics capable of handling unboxed types · 6cde981a
      Ryan Scott authored
      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
      6cde981a
    • thomie's avatar
      Testsuite: update expected output for T8602 · a96f1acc
      thomie authored
      a96f1acc
    • Tamar Christina's avatar
      Fix broken validation Build 6564 and accepting a few other test results · c4d7df04
      Tamar Christina authored
      Test Plan: ./validate
      
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1304
      c4d7df04
    • Tamar Christina's avatar
      Prevent GHC from silently dying when preprocessor is not found · b6f76b9a
      Tamar Christina authored
      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
      b6f76b9a
  11. 02 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Fix treatment of -0.0 · eb975d2e
      Ben Gamari authored
      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
      eb975d2e
  12. 30 Sep, 2015 1 commit
  13. 26 Sep, 2015 1 commit
    • Ömer Sinan Ağacan's avatar
      reify associated types when reifying typeclasses(#10891) · b4d43b4e
      Ömer Sinan Ağacan authored
      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
      b4d43b4e
  14. 25 Sep, 2015 1 commit
  15. 24 Sep, 2015 4 commits