1. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
    • Simon Peyton Jones's avatar
      Revert "Make the Ord Module independent of Unique order" · 70a45893
      Simon Peyton Jones authored
      This reverts commit 0497ee50.
      
      Reason: See Trac #12191.  I'm reverting pending Bartosz's
      investigation of what went wrong.
      70a45893
  2. 13 Jun, 2016 2 commits
    • niteria's avatar
      Make the Ord Module independent of Unique order · 0497ee50
      niteria authored
      The `Ord Module` instance currently uses `Unique`s for comparison.
      We don't want to use the `Unique` order because it can introduce nondeterminism.
      This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic ordering
      making `Ord Module` deterministic transitively.
      
      I've run `nofib` and it doesn't make a measurable difference.
      
      See also Note [ModuleEnv determinism and performance].
      
      Test Plan:
      ./validate
      run nofib: P112
      
      Reviewers: simonpj, simonmar, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2030
      
      GHC Trac Issues: #4012
      0497ee50
    • niteria's avatar
      Kill unused foldModuleEnv · 7de776cf
      niteria authored
      With the current implementation, it's nondeterministic
      because Ord Module is nondeterministic.
      7de776cf
  3. 11 Jun, 2016 1 commit
  4. 09 Jun, 2016 3 commits
  5. 08 Jun, 2016 1 commit
  6. 07 Jun, 2016 2 commits
    • niteria's avatar
      Kill varSetElems · 7008515b
      niteria authored
      This eradicates varSetElems from the codebase. This function
      used to introduce nondeterminism.
      I've also documented benign nondeterminism in three places.
      
      GHC Trac: #4012
      7008515b
    • niteria's avatar
      Kill occSetElts · 77ccdf3b
      niteria authored
      It uses uniqSetToList which is nondeterministic.
      
      GHC Trac: #4012
      77ccdf3b
  7. 06 Jun, 2016 3 commits
    • niteria's avatar
      Kill nameSetElems · 31ba8d64
      niteria authored
      nameSetElems used `eltsUFM` which is nondeterministic.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2305
      
      GHC Trac Issues: #4012
      31ba8d64
    • niteria's avatar
      Desugar ApplicativeDo and RecDo deterministically · e684f546
      niteria authored
      This fixes a problem described in
      Note [Deterministic ApplicativeDo and RecursiveDo desugaring].
      
      Test Plan: ./validate + new testcase
      
      Reviewers: simonpj, bgamari, austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2287
      
      GHC Trac Issues: #4012
      e684f546
    • 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
  8. 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
  9. 02 Jun, 2016 3 commits
  10. 27 May, 2016 1 commit
  11. 24 May, 2016 3 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
      Document some benign nondeterminism · 4c6e69d5
      niteria authored
      I've changed the functions to their nonDet equivalents and explained
      why they're OK there. This allowed me to remove foldNameSet,
      foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly.
      
      Test Plan: ./validate, there should be no change in behavior
      
      Reviewers: simonpj, simonmar, austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2244
      
      GHC Trac Issues: #4012
      4c6e69d5
    • Gabor Greif's avatar
      Spelling · 1bf5c126
      Gabor Greif authored
      1bf5c126
  12. 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
  13. 12 May, 2016 2 commits
  14. 11 May, 2016 1 commit
    • niteria's avatar
      Document SCC determinism · 3edbd091
      niteria authored
      I've documented the guarantees that stronglyConnCompFromEdgedVertices
      provides and commented on the call sites to explain why they are
      OK from determinism standpoint. I've changed the functions to
      nonDetUFM versions, so that it's explicit they could introduce
      nondeterminism.  I haven't defined container (VarSet, NameSet)
      specific versions, so that we have less functions to worry about.
      
      Test Plan: this is mostly just documentation,
      it should have no runtime effect
      
      Reviewers: bgamari, simonmar, austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2194
      
      GHC Trac Issues: #4012
      3edbd091
  15. 10 May, 2016 1 commit
    • niteria's avatar
      Make simplifyInstanceContexts deterministic · b58b0e18
      niteria authored
      simplifyInstanceContexts used cmpType which is nondeterministic
      for canonicalising typeclass constraints in derived instances.
      Following changes make it deterministic as explained by the
      Note [Deterministic simplifyInstanceContexts].
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2173
      
      GHC Trac Issues: #4012
      b58b0e18
  16. 04 May, 2016 1 commit
    • niteria's avatar
      Kill non-deterministic foldUFM in TrieMap and TcAppMap · ad4392c1
      niteria authored
      Summary:
      foldUFM introduces unnecessary non-determinism that actually
      leads to different generated code as explained in
      Note [TrieMap determinism].
      
      As we're switching from UniqFM to UniqDFM here you might be
      concerned about performance. There's nothing that ./validate
      detects. nofib reports no change in Compile Allocations, but
      Compile Time got better on some tests and worse on some,
      yielding this summary:
      
              -1 s.d.                -----            -3.8%
              +1 s.d.                -----            +5.4%
              Average                -----            +0.7%
      
      This is not a fair comparison as the order of Uniques
      changes what GHC is actually doing. One benefit from making
      this deterministic is also that it will make the
      performance results more stable.
      
      Full nofib results: P108
      
      Test Plan: ./validate, nofib
      
      Reviewers: goldfire, simonpj, simonmar, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2169
      
      GHC Trac Issues: #4012
      ad4392c1
  17. 30 Apr, 2016 1 commit
  18. 28 Apr, 2016 6 commits
    • niteria's avatar
      Remove unused foldNameEnv · 031de8bb
      niteria authored
      foldNameEnv is nondeterministic in the general case and it's
      currently unused so we can remove it.
      031de8bb
    • niteria's avatar
      Kill mapUniqSet · 73129231
      niteria authored
      Note [Unsound mapUniqSet] explains why it got removed.
      
      Test Plan: build ghc
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2152
      73129231
    • niteria's avatar
      Add uniqSetAny and uniqSetAll and use them · 3c426b05
      niteria authored
      There are couple of places where we do `foldUniqSet` just to
      compute `any` or `all`. `foldUniqSet` is non-deterministic in the
      general case and `any` and `all` also read nicer.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2156
      
      GHC Trac Issues: #4012
      3c426b05
    • niteria's avatar
      Kill unused foldOccSet · 3a53380d
      niteria authored
      foldOccSet if used would be a potential source of nondeterminism.
      Since it's not used we can just remove it.
      3a53380d
    • Simon Peyton Jones's avatar
      Refactor RecordPatSynField, FieldLabel · 3dce4f2d
      Simon Peyton Jones authored
      This patch uses the named fields of
       * FieldLabel
       * RecordPatSynField
      in construction and pattern matching. The fields
      existed before, but we were often using positional notation.
      
      Also a minor refactor of the API of mkPatSynRecSelBinds
      
      No change in functionality
      3dce4f2d
    • niteria's avatar
      Expand the comment on pprVarSet · fa3ba060
      niteria authored
      fa3ba060
  19. 27 Apr, 2016 1 commit
    • Joachim Breitner's avatar
      Implement the state hack without modifiyng OneShotInfo · a48ebcc4
      Joachim Breitner authored
      Previously, the state hack would be implemented in mkLocalId, by looking
      at the type, and setting the OneShot flag accordingly.
      
      This patch changes this so that the OneShot flag faithfully represents
      what our various analyses found out, and the State Hack is implemented
      by adjusting the accessors, in particular isOneShotBndr and
      idStateHackOneShotInfo. This makes it easier to understand what's going
      on in the analyses, and de-clutters core dumps and interface files.
      
      I don’t expect any change in behaviour, at least not in non-fringe
      cases.
      a48ebcc4
  20. 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
  21. 22 Apr, 2016 2 commits
    • niteria's avatar
      Make benign non-determinism in pretty-printing more obvious · 0f96686b
      niteria authored
      This change takes us one step closer to being able to remove
      `varSetElemsWellScoped`. The end goal is to make every source
      of non-determinism obvious at the source level, so that when
      we achieve determinism it doesn't get broken accidentally.
      
      Test Plan: compile GHC
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2123
      
      GHC Trac Issues: #4012
      0f96686b
    • Simon Peyton Jones's avatar
      Warn about simplifiable class constraints · 9421b0c7
      Simon Peyton Jones authored
      Provoked by Trac #11948, this patch adds a new warning to GHC
      
        -Wsimplifiable-class-constraints
      
      It warns if you write a class constraint in a type signature that
      can be simplified by an existing instance declaration.  Almost always
      this means you should simplify it right now; type inference is very
      fragile without it, as #11948 shows.
      
      I've put the warning as on-by-default, but I suppose that if there are
      howls of protest we can move it out (as happened for -Wredundant-constraints.
      
      It actually found an example of an over-complicated context in CmmNode.
      
      Quite a few tests use these weird contexts to trigger something else,
      so I had to suppress the warning in those.
      
      The 'haskeline' library has a few occurrences of the warning (which
      I think should be fixed), so I switched it off for that library in
      warnings.mk.
      
      The warning itself is done in TcValidity.check_class_pred.
      
      HOWEVER, when type inference fails we get a type error; and the error
      suppresses the (informative) warning.  So as things stand, the warning
      only happens when it doesn't cause a problem.  Not sure what to do
      about this, but this patch takes us forward, I think.
      9421b0c7
  22. 20 Apr, 2016 1 commit