1. 30 Aug, 2018 2 commits
  2. 29 Aug, 2018 3 commits
    • David Feuer's avatar
      Finish stable split · f48e276a
      David Feuer authored
      Long ago, the stable name table and stable pointer tables were one.
      Now, they are separate, and have significantly different
      implementations. I believe the time has come to finish the split
      that began in #7674.
      * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`.
      * Give each table its own mutex.
      * Add FFI functions `hs_lock_stable_ptr_table` and
      `hs_unlock_stable_ptr_table` and document them.
        These are intended to replace the previously undocumented
      `hs_lock_stable_tables` and `hs_lock_stable_tables`,
        which are now documented as deprecated synonyms.
      * Make `eqStableName#` use pointer equality instead of unnecessarily
      comparing stable name table indices.
      Reviewers: simonmar, bgamari, erikd
      Reviewed By: bgamari
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15555
      Differential Revision: https://phabricator.haskell.org/D5084
    • Andrey Mokhov's avatar
      Fix a constant folding rule · 65eec9cf
      Andrey Mokhov authored
      One of the constant folding rules introduced in D2858 is:
      (L y :-:   v) :-: (L x :-: w) -> return $ mkL (y-x)   `add` (w `add` v)
      Or, after removing syntactic noise: `(y - v) - (x - w) ==> (y - x) + (w + v)`.
      This is incorrect, since the sign of `v` is changed from negative to positive.
      As a consequence, the following program prints `3` when compiled with `-O`:
      -- This is just subtraction in disguise
      minus :: Int -> Int -> Int
      minus x y = (8 - y) - (8 - x)
      {-# NOINLINE minus #-}
      main :: IO ()
      main = print (2 `minus` 1)
      The correct rule is: `(y - v) - (x - w) ==> (y - x) + (w - v)`.
      This commit does the fix. I haven't found any other issues with the constant
      folding code, but it's difficult to be certain without some automated checking.
      Reviewers: bgamari, tdammers
      Subscribers: hsyl20, tdammers, rwbarton, carter
      GHC Trac Issues: #15569
      Differential Revision: https://phabricator.haskell.org/D5109
    • chris-bacon's avatar
      Fixed typo in exponent example · 36c1431d
      chris-bacon authored
  3. 28 Aug, 2018 4 commits
    • Ryan Scott's avatar
      Rename kind vars in left-to-right order in bindHsQTyVars · 102284e7
      Ryan Scott authored
      When renaming kind variables in an `LHsQTyVars`, we were
      erroneously putting all of the kind variables in the binders
      //after// the kind variables in the body, resulting in #15568. The
      fix is simple: just swap the order of these two around.
      Test Plan: make test TEST=T15568
      Reviewers: simonpj, bgamari, goldfire
      Reviewed By: goldfire
      Subscribers: goldfire, rwbarton, carter
      GHC Trac Issues: #15568
      Differential Revision: https://phabricator.haskell.org/D5108
    • Krzysztof Gogolewski's avatar
      Fix typo in 8.6.1 notes · 34b8e613
      Krzysztof Gogolewski authored
    • Ryan Scott's avatar
      Fix #15572 by checking for promoted names in ConT · c46a5f20
      Ryan Scott authored
      When converting `ConT`s to `HsTyVar`s in `Convert`, we were
      failing to account for the possibility of promoted data constructor
      names appearing in a `ConT`, which could result in improper
      pretty-printing results (as observed in #15572). The fix is
      straightforward: use `Promoted` instead of `NotPromoted` when the
      name of a `ConT` is a data constructor name.
      Test Plan: make test TEST=T15572
      Reviewers: goldfire, bgamari, simonpj, monoidal
      Reviewed By: goldfire, simonpj
      Subscribers: monoidal, rwbarton, carter
      GHC Trac Issues: #15572
      Differential Revision: https://phabricator.haskell.org/D5112
    • Krzysztof Gogolewski's avatar
      Remove dead code for commandline parsing · c18b525a
      Krzysztof Gogolewski authored
      PrefixPred and AnySuffixPred are not used
      since static flags were removed in bbd3c399.
      Test Plan: validate
      Reviewers: bgamari, tdammers
      Reviewed By: tdammers
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5111
  4. 27 Aug, 2018 8 commits
    • Ben Gamari's avatar
      rts: Handle SMALL_MUT_ARR_PTRS in retainer profilter · 2cf98e22
      Ben Gamari authored
      Summary: These can be treated similarly to MUT_ARRY_PTRS. Fixes #15529.
      Reviewers: erikd, simonmar
      Reviewed By: simonmar
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #15529
      Differential Revision: https://phabricator.haskell.org/D5075
    • Chaitanya Koparkar's avatar
      Remove dph, vector, primitive and random from .gitmodules · 154d4e21
      Chaitanya Koparkar authored
      These packages were removed from the GHC source tree in
      Phab:D4761 and 0905fec0.
      Reviewers: RyanGlScott, bgamari
      Reviewed By: RyanGlScott
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5095
    • Krzysztof Gogolewski's avatar
      Bump nofib submodule · b1f5d2fd
      Krzysztof Gogolewski authored
    • Chaitanya Koparkar's avatar
      Fix #10859 by using foldr1 while deriving Eq instances · 2d953a60
      Chaitanya Koparkar authored
      Previously, we were using foldl1 instead, which led to the derived
      code to be wrongly associated.
      Test Plan: ./validate
      Reviewers: RyanGlScott, nomeata, simonpj, bgamari
      Reviewed By: RyanGlScott, nomeata
      Subscribers: rwbarton, carter
      GHC Trac Issues: #10859
      Differential Revision: https://phabricator.haskell.org/D5104
    • Ryan Scott's avatar
      Don't reify redundant class method tyvars/contexts · 6e765aeb
      Ryan Scott authored
      Currently, reifying classes produces class methods with
      redundant tyvars and class contexts in their type signatures, such
      as in the following:
      class C a where
        method :: forall a. C a => a
      Fixing this is very straightforward: just apply `tcSplitMethodTy` to
      the type of each class method to lop off the redundant parts.
      It's possible that this could break some TH code in the wild that
      assumes the existence of these tyvars and class contexts, so I'll
      advertise this change in the release notes just to be safe.
      Test Plan: make test TEST="TH_reifyDecl1 T9064 T10891 T14888"
      Reviewers: goldfire, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, carter
      GHC Trac Issues: #15551
      Differential Revision: https://phabricator.haskell.org/D5088
    • Ryan Scott's avatar
      Take strict fields into account in coverage checking · 744b034d
      Ryan Scott authored
      The current pattern-match coverage checker implements the
      formalism presented in the //GADTs Meet Their Match// paper in a
      fairly faithful matter. However, it was discovered recently that
      there is a class of unreachable patterns that
      //GADTs Meet Their Match// does not handle: unreachable code due to
      strict argument types, as demonstrated in #15305. This patch
      therefore goes off-script a little and implements an extension to
      the formalism presented in the paper to handle this case.
      Essentially, when determining if each constructor can be matched on,
      GHC checks if its associated term and type constraints are
      satisfiable. This patch introduces a new form of constraint,
      `NonVoid(ty)`, and checks if each constructor's strict argument types
      satisfy `NonVoid`. If any of them do not, then that constructor is
      deemed uninhabitable, and thus cannot be matched on. For the full
      story of how this works, see
      `Note [Extensions to GADTs Meet Their Match]`.
      Along the way, I did a little bit of much-needed refactoring. In
      particular, several functions in `Check` were passing a triple of
      `(ValAbs, ComplexEq, Bag EvVar)` around to represent a constructor
      and its constraints. Now that we're adding yet another form of
      constraint to the mix, I thought it appropriate to turn this into
      a proper data type, which I call `InhabitationCandidate`.
      Test Plan: make test TEST=T15305
      Reviewers: simonpj, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15305
      Differential Revision: https://phabricator.haskell.org/D5087
    • Ryan Scott's avatar
      Fix #15502 by not casting to Int during TH conversion · 7a3cda53
      Ryan Scott authored
      When turning an `IntegerL` to an `IntegralLit` during TH
      conversion, we were stupidly casting an `Integer` to an `Int` in
      order to determine how it should be pretty-printed. Unsurprisingly,
      this causes problems when the `Integer` doesn't lie within the bounds
      of an `Int`, as demonstrated in #15502.
      The fix is simple: don't cast to an `Int`.
      Test Plan: make test TEST=T15502
      Reviewers: bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, carter
      GHC Trac Issues: #15502
      Differential Revision: https://phabricator.haskell.org/D5089
    • Ryan Scott's avatar
      Fix #15550 by quoting RULE names during TH conversion · 5e6cf2a9
      Ryan Scott authored
      When converting a `RuleP` to a GHC source `RuleD` during TH
      conversion, we were stupidly not double-quoting the name of the rule.
      Easily fixed.
      Test Plan: make test TEST=T15550
      Reviewers: goldfire, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, carter
      GHC Trac Issues: #15550
      Differential Revision: https://phabricator.haskell.org/D5090
  5. 25 Aug, 2018 1 commit
    • Tamar Christina's avatar
      ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0 · c523525b
      Tamar Christina authored
      This completes the work started in D4227 by using just 'getExecutablePath'
      in ghc and ghc-pkg when building with base >= 4.11.0.
      On the long term, we will be able to simply kill the existing code that
      follows (or not) symlinks and just get this behaviour for free from
      getExecutable. For now we however have to require base >= 4.11.0 to be able
      to just use getExecutablePath under Windows, and use the current code when
      building with an older base.
      Original code by @alpmestan commandeering since patch has been stale
      and bug remains open.
      Test Plan: Validate
      Reviewers: angerman, bgamari, erikd, alpmestan
      Reviewed By: bgamari
      Subscribers: carter, rwbarton, thomie
      GHC Trac Issues: #14483
      Differential Revision: https://phabricator.haskell.org/D4229
  6. 24 Aug, 2018 7 commits
    • Simon Peyton Jones's avatar
      Better error reporting for inaccessible code · ff29fc84
      Simon Peyton Jones authored
      This patch fixes Trac #15558.  There turned out to be
      two distinct problems
      * In TcExpr.tc_poly_expr_nc we had
          tc_poly_expr_nc (L loc expr) res_ty
            = do { traceTc "tcPolyExprNC" (ppr res_ty)
                 ; (wrap, expr')
                     <- tcSkolemiseET GenSigCtxt res_ty $ \ res_ty ->
                        setSrcSpan loc $
                          -- NB: setSrcSpan *after* skolemising,
                          -- so we get better skolem locations
                        tcExpr expr res_ty
        Putting the setSrcSpan inside the tcSkolemise means that
        the location on the Implication constraint is the /call/
        to the function rather than the /argument/ to the call,
        and that is really quite wrong.
        I don't know what Richard's comment NB means -- I moved the
        setSrcSpan outside, and the "binding site" info in error
        messages actually improved.
        The reason I found this is that it affects the span reported
        for Trac #15558.
      * In TcErrors.mkGivenErrorReporter we carefully munge the location
        for an insoluble Given constraint (Note [Inaccessible code]).
        But the 'implic' passed in wasn't necesarily the immediately-
        enclosing implication -- but for location-munging purposes
        it jolly well should be.
        Solution: use the innermost implication. This actually
        simplifies the code -- no need to pass an implication in to
    • Simon Peyton Jones's avatar
      Add comments about pretty-printing via IfaceSyn · 4b79329f
      Simon Peyton Jones authored
      Provoked by discussion on Phab:D5097 (Trac #15546), I'm adding
      a big Note explaing the strategy of pretty-printing via IfaceSyn
    • Simon Peyton Jones's avatar
      Comments only · 1cca4423
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Clean up TcHsSyn.zonkEnv · 184a569c
      Simon Peyton Jones authored
      Triggered by Trac #15552, I'd been looking at ZonkEnv in TcHsSyn.
      This patch does some minor refactoring
      * Make ZonkEnv into a record with named fields, and use them.
        (I'm planning to add a new field, for TyCons, so this prepares
        the way.)
      * Replace UnboundTyVarZonker (a higer order function) with the
        simpler and more self-descriptive ZonkFlexi data type, below.
       It's just much more perspicuous and direct, and (I suspect)
       a tiny bit faster too -- no unknown function calls.
      data ZonkFlexi   -- See Note [Un-unified unification variables]
        = DefaultFlexi    -- Default unbound unificaiton variables to Any
        | SkolemiseFlexi  -- Skolemise unbound unification variables
                          -- See Note [Zonking the LHS of a RULE]
        | RuntimeUnkFlexi -- Used in the GHCi debugger
      There was one knock-on effect in the GHCi debugger -- the
      RuntimeUnkFlexi case.  Somehow previously, these RuntimeUnk
      variables were sometimes getting SystemNames (and hence
      printed as 'a0', 'a1', etc) and sometimes not (and hence
      printed as 'a', 'b' etc).  I'm not sure precisely why, but
      the new behaviour seems more uniform, so I just accepted the
      (small) renaming wibbles in some ghci.debugger tests.
      I had a quick look at perf: any changes are tiny.
    • Artem Pelenitsyn's avatar
      Update unicode tables to v. 12 of the standard · 14d88380
      Artem Pelenitsyn authored
      Reviewers: hvr, bgamari, Azel
      Reviewed By: bgamari
      Subscribers: thomie, Azel, rwbarton, carter
      GHC Trac Issues: #5518, #15525
      Differential Revision: https://phabricator.haskell.org/D5066
    • Ben Gamari's avatar
    • Ben Gamari's avatar
      TcSimplify: Condense MASSERT2() usage onto a single line · 8d72f878
      Ben Gamari authored
      Sadly macOS's C preprocessor gets angry at the sight of multi-line macro
  7. 23 Aug, 2018 3 commits
    • Simon Peyton Jones's avatar
      Accommodate API change in transSuperClasses · 4293a80a
      Simon Peyton Jones authored
      In this patch
          commit 6eabb6dd
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Tue Dec 15 14:26:13 2015 +0000
          Allow recursive (undecidable) superclasses
      I changed (transSuperClasses p) to return only the
      superclasses of p, but not p itself. (Previously it always
      returned p as well.)
      The use of transSuperClasses in TcErrors.warnRedundantConstraints
      really needs 'p' in the result -- but I faild to fix this
      call site, and instead crippled the test for Trac #10100.
      This patch sets things right
      * Accomodates the API change
      * Re-enables T10100
      * And thereby fixes Trac #11474
    • Simon Peyton Jones's avatar
      Comments only · 2a54209f
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Fix a typo in TcValidity.checkFamInstRhs · 8c7f90ab
      Simon Peyton Jones authored
      In error message generation we were using the wrong
      type constructor in inst_head.  Result: the type became
      ill-kinded, and that sent the compiler into a loop.
      A separate patch fixes the loop. This patch fixes the
      actual bug -- Trac #15473.
      I also improved the "occurs more often" error message
      a bit.  But it's still pretty terrible:
          * Variable ‘a’ occurs more often
            in the type family application ‘Undefined’
            than in the instance head ‘LetInterleave xs t ts is y z’
      It looks like nonsense, but all becomes clear if you use
      -fprint-explicit-kinds.  Really we should fix this by spotting
      when invisible arguments are involved and at least suggesting
  8. 22 Aug, 2018 3 commits
  9. 21 Aug, 2018 9 commits