1. 30 Jun, 2016 1 commit
    • niteria's avatar
      Remove ufmToList · 480e0661
      niteria authored
      This documents nondeterminism in code generation and removes
      the nondeterministic ufmToList function. In the future someone
      will have to use nonDetUFMToList (with proper explanation)
      or pprUFMWithKeys.
      480e0661
  2. 06 Jun, 2016 2 commits
    • niteria's avatar
      Make UnitIdMap a deterministic map · 1937ef1c
      niteria authored
      This impacts at least the order in which version macros are
      generated. It's pretty hard to track what kind of nondeterminism
      is benign and this should have no performance impact as the number
      of packages should be relatively small.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, austin, bgamari, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2308
      
      GHC Trac Issues: #4012
      1937ef1c
    • niteria's avatar
      Use UniqDFM for HomePackageTable · 3042a9d8
      niteria authored
      This isn't strictly necessary for deterministic ABIs.
      The results of eltsHpt are consumed in two ways:
      1) they determine the order of linking
      2) if you track the data flow all the family instances get put in
         FamInstEnvs, so the nondeterministic order is forgotten.
      3) same for VectInfo stuff
      4) same for Annotations
      
      The problem is that I haven't found a nice way to do 2. in
      a local way and 1. is nice to have if we went for deterministic
      object files. Besides these maps are keyed on ModuleNames so they
      should be small relative to other things and the overhead should
      be negligible.
      
      As a bonus we also get more specific names.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, hvr, ezyang, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2300
      
      GHC Trac Issues: #4012
      3042a9d8
  3. 03 Jun, 2016 1 commit
    • niteria's avatar
      Make FieldLabelEnv a deterministic set · 9cc6fac5
      niteria authored
      This lets us kill fsEnvElts function which is nondeterministic.
      We also get better guarantees than just comments.
      We don't do lookups, but I believe a set is needed for deduplication.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, mpickering, austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2297
      
      GHC Trac Issues: #4012
      9cc6fac5
  4. 24 May, 2016 2 commits
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Summary:
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: austin, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2260
      95dfdceb
    • niteria's avatar
      Make Arrow desugaring deterministic · 9d06ef1a
      niteria authored
      This kills two instances of varSetElems that turned out to be
      nondeterministic. I've tried to untangle this before, but it's
      a bit hard with the fixDs in the middle. Fortunately I now have
      a test case that proves that we need determinism here.
      
      Test Plan: ./validate, new testcase
      
      Reviewers: simonpj, simonmar, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2258
      
      GHC Trac Issues: #4012
      9d06ef1a
  5. 18 May, 2016 1 commit
    • niteria's avatar
      Make inert_model and inert_eqs deterministic sets · fffe3a25
      niteria authored
      The order inert_model and intert_eqs fold affects the order that the
      typechecker looks at things. I've been able to experimentally confirm
      that the order of equalities and the order of the model matter for
      determinism. This is just a straigthforward replacement of
      nondeterministic VarEnv for deterministic DVarEnv.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2232
      
      GHC Trac Issues: #4012
      fffe3a25
  6. 12 May, 2016 1 commit
  7. 26 Apr, 2016 1 commit
    • niteria's avatar
      Kill varSetElemsWellScoped in quantifyTyVars · c9bcaf31
      niteria authored
      varSetElemsWellScoped introduces unnecessary non-determinism in
      inferred type signatures.
      Removing this instance required changing the representation of
      TcDepVars to use deterministic sets.
      This is the last occurence of varSetElemsWellScoped, allowing me to
      finally remove it.
      
      Test Plan:
      ./validate
      I will update the expected outputs when commiting, some reordering
      of type variables in types is expected.
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2135
      
      GHC Trac Issues: #4012
      c9bcaf31
  8. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  9. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  10. 02 Dec, 2015 1 commit
  11. 21 Nov, 2015 1 commit
    • niteria's avatar
      Add DVarSet - a deterministic set of Vars · 6664ab83
      niteria authored
      This implements `DVarSet`, a deterministic set of Vars, with an
      interface very similar to `VarSet` with a couple of functions missing.
      
      I will need this in changes that follow, one of them will be about
      changing the type of the set of Vars that `RuleInfo` holds to make the
      free variable computation deterministic.
      
      Test Plan:
      ./validate
      I can add new tests if anyone wants me to.
      
      Reviewers: simonpj, simonmar, austin, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1487
      
      GHC Trac Issues: #4012
      6664ab83
  12. 30 Oct, 2015 1 commit
    • niteria's avatar
      Make type-class dictionary let binds deterministic · a5cb27f3
      niteria authored
      When generating dictionary let binds in dsTcEvBinds we may
      end up generating them in arbitrary order according to Unique order.
      
      Consider:
      
      ```
      let $dEq = GHC.Classes.$fEqInt in
      let $$dNum = GHC.Num.$fNumInt in ...
      ```
      
      vs
      
      ```
      let $dNum = GHC.Num.$fNumInt in
      let $dEq = GHC.Classes.$fEqInt in ...
      ```
      
      The way this change fixes it is by using `UniqDFM` - a type of
      deterministic finite maps of things keyed on `Unique`s. This way when
      you pull out evidence variables corresponding to type-class dictionaries
      they are in deterministic order.
      
      Currently it's the order of insertion and the way it's implemented is by
      tagging the values with the time of insertion.
      
      Test Plan:
      I've added a new test case to reproduce the issue.
      ./validate
      
      Reviewers: ezyang, simonmar, austin, simonpj, bgamari
      
      Reviewed By: simonmar, simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1396
      
      GHC Trac Issues: #4012
      a5cb27f3