1. 17 Apr, 2016 2 commits
    • Iavor S. Diatchki's avatar
      Add TemplateHaskell support for Overlapping pragmas · 04b70cda
      Iavor S. Diatchki authored
      Reviewers: hvr, goldfire, austin, RyanGlScott, bgamari
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: RyanGlScott, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2118
      04b70cda
    • Tamar Christina's avatar
      Add Windows import library support to the Runtime Linker · 97f2b164
      Tamar Christina authored
      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
      97f2b164
  2. 15 Apr, 2016 4 commits
    • Simon Peyton Jones's avatar
      Improve TcFlatten.flattenTyVar · a7ee2d4c
      Simon Peyton Jones authored
      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.
      a7ee2d4c
    • Ben Gamari's avatar
      testsuite: Add test for #11827 · cb0d29b2
      Ben Gamari authored
      Test Plan: Validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2109
      
      GHC Trac Issues: #11827
      cb0d29b2
    • Ben Gamari's avatar
      testsuite: Add T11824 · 116088de
      Ben Gamari authored
      Test Plan: Validate
      
      Reviewers: goldfire, austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2107
      
      GHC Trac Issues: #11824
      116088de
    • Simon Peyton Jones's avatar
      Adjust error check for class method types · e24b3b1e
      Simon Peyton Jones authored
      Fixes Trac #11793.  Nothing deep here.
      e24b3b1e
  3. 14 Apr, 2016 2 commits
    • Joachim Breitner's avatar
      Add a final demand analyzer run right before TidyCore · f4fd98c7
      Joachim Breitner authored
      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
      f4fd98c7
    • Joachim Breitner's avatar
      Add a test case for #11731. · 3a34b5c3
      Joachim Breitner authored
      3a34b5c3
  4. 12 Apr, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Fix #11797. · dd99f2ec
      eir@cis.upenn.edu authored
      DsMeta curiously omitted quantified tyvars in certain circumstances.
      This patch means it doesn't.
      
      Test case: th/T11797
      dd99f2ec
    • eir@cis.upenn.edu's avatar
      Fix #11811. · b1084fd7
      eir@cis.upenn.edu authored
      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
      b1084fd7
  5. 11 Apr, 2016 3 commits
    • Ryan Scott's avatar
      Deriving Functor-like classes should unify kind variables · aadde2b9
      Ryan Scott authored
      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
      aadde2b9
    • Ryan Scott's avatar
      Filter out invisible kind arguments during TH reification · 02a5c580
      Ryan Scott authored
      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
      02a5c580
    • Rik Steenkamp's avatar
      Fix a closed type family error message · 46e8f199
      Rik Steenkamp authored
      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
      46e8f199
  6. 10 Apr, 2016 5 commits
    • Tamar Christina's avatar
      Change runtime linker to perform lazy loading of symbols/sections · 90538d86
      Tamar Christina authored
      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
      90538d86
    • Ryan Scott's avatar
      Remove the instantiation check when deriving Generic(1) · 7443e5c8
      Ryan Scott authored
      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
      7443e5c8
    • Jason Eisenberg's avatar
      Fix suggestions for unbound variables (#11680) · 470d4d5b
      Jason Eisenberg authored
      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
      470d4d5b
    • Herbert Valerio Riedel's avatar
      Reduce default for -fmax-pmcheck-iterations from 1e7 to 2e6 · d2e05c6b
      Herbert Valerio Riedel authored
      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
      d2e05c6b
    • bollmann's avatar
      Fix Template Haskell bug reported in #11809. · 2f82da76
      bollmann authored
      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
      2f82da76
  7. 08 Apr, 2016 1 commit
  8. 07 Apr, 2016 4 commits
  9. 06 Apr, 2016 6 commits
  10. 05 Apr, 2016 1 commit
  11. 04 Apr, 2016 4 commits
    • Eric Seidel's avatar
      Don't infer CallStacks · 7407a66d
      Eric Seidel authored
      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
      7407a66d
    • Simon Peyton Jones's avatar
      Elaborate test for #11376 · b3ecd047
      Simon Peyton Jones authored
      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
      b3ecd047
    • Jason Eisenberg's avatar
      rts: Make StablePtr derefs thread-safe (#10296) · 90d7d608
      Jason Eisenberg authored
      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
      90d7d608
    • Simon Peyton Jones's avatar
      Deeply instantiate in :type · f2a2b79f
      Simon Peyton Jones authored
      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.
      f2a2b79f
  12. 02 Apr, 2016 1 commit
    • Rik Steenkamp's avatar
      Improve printing of pattern synonym types · 72bd7f7b
      Rik Steenkamp authored
      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
      72bd7f7b
  13. 31 Mar, 2016 3 commits
  14. 30 Mar, 2016 2 commits