1. 01 Nov, 2015 3 commits
  2. 31 Oct, 2015 1 commit
  3. 30 Oct, 2015 12 commits
    • Sergei Trofimovich's avatar
    • Sergei Trofimovich's avatar
    • 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
    • Matthew Pickering's avatar
      Add failing test for #11039 · fce758c5
      Matthew Pickering authored
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1406
      
      GHC Trac Issues: #11039
      fce758c5
    • Edward Z. Yang's avatar
      Reimplement shadowing on a per database basis. · 39b71e81
      Edward Z. Yang authored
      
      
      Summary:
      This commit reimplements shadowing on package databases by doing
      the shadowing calculation on a per-database basis: specifically,
      if a later package database shadows a package from the earlier
      databases, we first remove that package (and its transitive
      dependencies) before merging the databases together.
      
      This should also fix bootstrapping GHC HEAD with HEAD.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: ggreif, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1385
      39b71e81
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
    • thomie's avatar
      Testsuite: suggest quoting $(TEST_HC) · 59e728bc
      thomie authored
      Test Plan: it works
      
      Reviewers: bgamari, rwbarton, austin
      
      Reviewed By: austin
      
      Subscribers: rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D1377
      59e728bc
    • Ben Gamari's avatar
      CmmParse: Expose popcnt operations · 42e85284
      Ben Gamari authored
      Make various population count operations available via C-- syntax
      under the names %popcnt{8,16,32,64}. Fixes #11037.
      
      Reviewers: simonmar, austin, ekmett
      
      Reviewed By: austin, ekmett
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1402
      
      GHC Trac Issues: #11037
      42e85284
    • Adam Gundry's avatar
      Disambiguate record selectors by type signature · 0a163741
      Adam Gundry authored
      This makes DuplicateRecordFields more liberal in when it will
      accept ambiguous record selectors, making use of type information in a
      similar way to updates. See Note [Disambiguating record fields] for more
      details. I've also refactored how record updates are disambiguated.
      
      Test Plan: New and amended tests in overloadedrecflds
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1391
      0a163741
    • thomie's avatar
    • Simon Peyton Jones's avatar
      Record usage information using GlobalRdrElt · 3e94842d
      Simon Peyton Jones authored
      This patch implements an improvment that I've wanted to do for ages, but
      never gotten around to.
      
      Unused imports are computed based on how imported entities occur (qualified,
      unqualified).   This info was accumulated in tcg_used_rdrnames :: Set RdrName.
      But that was a huge pain, and it got worse when we introduced duplicate
      record fields.
      
      The Right Thing is to record tcg_used_gres :: [GlobalRdrElt], which records
      the GRE *after* filtering with pickGREs.  See Note [GRE filtering] in RdrName.
      This is much, much bette.  This patch deletes quite a bit of code, and is
      conceptually much easier to follow.
      
      Hooray.  There should be no change in functionality.
      3e94842d
    • Simon Peyton Jones's avatar
      Fix unused-import stuff in a better way · 9376249b
      Simon Peyton Jones authored
      The fix for Trac #10890 in commit 1818b48e, namely
         Fix incorrect import warnings when methods with identical names are imported
      was wrong, as demonstrated by the new test T10890_2.  It suppressed
      far too many warnings!
      
      This patch fixes the original problem in a different way, by making
      RdrName.greUsedRdrName a bit cleverer.
      
      But this too is not really the Right Thing.  I think the Right Thing is
      to store the /GRE/ in the tcg_used_rdrnames, not the /RdrName/.  That
      would be a lot simpler and more direct.
      
      But one step at a time.
      9376249b
  4. 29 Oct, 2015 6 commits
    • Sergei Trofimovich's avatar
      x86 codegen: don't generate location comments · e272ab99
      Sergei Trofimovich authored
      
      
      The following source snippet 'module A where x */* y = 42'
      when being compiled with '-g' option emits syntactically
      invalid comment for GNU as:
      
          .text
              .align 8
              .loc 1 3 1 /* */* */
      
      Fixed by not emitting comments at all. We already suppress
      all asm comments in 'X86/Ppr.hs'.
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Test Plan: added test and check it works
      
      Reviewers: scpmw, simonmar, austin, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1386
      
      GHC Trac Issues: #10667
      e272ab99
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
    • Matthew Pickering's avatar
      Record pattern synonyms · 2a74a64e
      Matthew Pickering authored
      This patch implements an extension to pattern synonyms which allows user
      to specify pattern synonyms using record syntax. Doing so generates
      appropriate selectors and update functions.
      
      === Interaction with Duplicate Record Fields ===
      
      The implementation given here isn't quite as general as it could be with
      respect to the recently-introduced `DuplicateRecordFields` extension.
      
      Consider the following module:
      
          {-# LANGUAGE DuplicateRecordFields #-}
          {-# LANGUAGE PatternSynonyms #-}
      
          module Main where
      
          pattern S{a, b} = (a, b)
          pattern T{a}    = Just a
      
          main = do
            print S{ a = "fst", b = "snd" }
            print T{ a = "a" }
      
      In principle, this ought to work, because there is no ambiguity. But at
      the moment it leads to a "multiple declarations of a" error. The problem
      is that pattern synonym record selectors don't do the same name mangling
      as normal datatypes when DuplicateRecordFields is enabled. They could,
      but this would require some work to track the field label and selector
      name separately.
      
      In particular, we currently represent datatype selectors in the third
      component of AvailTC, but pattern synonym selectors are just represented
      as Avails (because they don't have a corresponding type constructor).
      Moreover, the GlobalRdrElt for a selector currently requires it to have
      a parent tycon.
      
      (example due to Adam Gundry)
      
      === Updating Explicitly Bidirectional Pattern Synonyms ===
      
      Consider the following
      
      ```
      pattern Silly{a} <- [a] where
        Silly a = [a, a]
      
      f1 = a [5] -- 5
      
      f2 = [5] {a = 6} -- currently [6,6]
      ```
      
      === Fixing Polymorphic Updates ===
      
      They were fixed by adding these two lines in `dsExpr`. This might break
      record updates but will be easy to fix.
      
      ```
      + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)
      
      - , pat_wrap = idHsWrapper }
      +, pat_wrap = req_wrap }
      ```
      
      === Mixed selectors error ===
      
      Note [Mixed Record Field Updates]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Consider the following pattern synonym.
      
          data MyRec = MyRec { foo :: Int, qux :: String }
      
          pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}
      
      This allows updates such as the following
      
          updater :: MyRec -> MyRec
          updater a = a {f1 = 1 }
      
      It would also make sense to allow the following update (which we
      reject).
      
          updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"
      
      This leads to confusing behaviour when the selectors in fact refer the
      same field.
      
          updater a = a {f1 = 1, foo = 2} ==? ???
      
      For this reason, we reject a mixture of pattern synonym and normal
      record selectors in the same update block. Although of course we still
      allow the following.
      
          updater a = (a {f1 = 1}) {foo = 2}
      
          > updater (MyRec 0 "str")
          MyRec 2 "str"
      2a74a64e
    • thomie's avatar
      Testsuite: report and error out on unfound tests · 032be43b
      thomie authored
      Users are sometimes confused why their test doesn't run. It is usually
      because of a misspelled testname, for example using 'TEST=1234' instead
      of 'TEST=T1234'. After this patch it is hopefully more clear what the
      problem is, showing:
      
          ERROR: tests not found: ['1234']
      
      Instead of:
      
          0 total tests, which gave rise to
          0 test cases, of which
          0 were skipped
      
      Reviewed by: austin, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1388
      032be43b
    • Erik de Castro Lopo's avatar
      Fix rts/T9579 tests on OS X · ce2416bc
      Erik de Castro Lopo authored
      Sed on OS X does not understand 's/[0-9]\+ bytes/NUM bytes/g' but
      sed on Linux and OS X do understand 's/[0-9]* bytes/NUM bytes/g'.
      
      Test Plan: Run all rts/T9579 tests on Linux and Mac
      
      Reviewers: thomie, austin, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1394
      ce2416bc
  5. 28 Oct, 2015 1 commit
    • Simon Peyton Jones's avatar
      Pattern synonyms: swap provided/required · 04b0a73a
      Simon Peyton Jones authored
      This patch swaps the order of provided and required constraints in
      a pattern signature, so it now goes
      
            pattern P :: req => prov => t1 -> ... tn -> res_ty
      
      See the long discussion in Trac #10928.
      
      I think I have found all the places, but I could have missed something
      particularly in comments.
      
      There is a Haddock changes; so a submodule update.
      04b0a73a
  6. 27 Oct, 2015 5 commits
  7. 26 Oct, 2015 3 commits
  8. 25 Oct, 2015 1 commit
    • Alan Zimmerman's avatar
      Provide a utility to check API Annotations · 43751b24
      Alan Zimmerman authored
      It is difficult for GHC developers to know if they have broken the API
      Annotations.
      
      This patch provides a utility that can be used as a test to show up
      errors in the API Annotations.
      
      It is based on the current tests for ghc-api/annotations which can parse
      a file using the just-built GHC API, and check that no annotations are
      disconnected from the ParsedSource in the output.
      
      In addition, it should be able to dump the annotations to a file, so a
      new feature developer can check that all changes to the parser do
      provide annotations.
      
      Trac ticket: #10917
      
      Test Plan: ./validate
      
      Reviewers: hvr, thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1368
      
      GHC Trac Issues: #10917
      43751b24
  9. 23 Oct, 2015 1 commit
  10. 22 Oct, 2015 4 commits
    • niteria's avatar
      Make stronglyConnCompFromEdgedVertices deterministic · 9cb192ce
      niteria authored
      This makes it so the result of computing SCC's depends on the order
      the nodes were passed to it, but not on the order on the user provided
      key type.
      The key type is usually `Unique` which is known to be nondeterministic.
      
      Test Plan:
      `text` and `aeson` become deterministic after this
      ./validate
      
      Compare compile time for `text`:
      ```
      $ cabal get text && cd text* && cabal sandbox init && cabal install
      --dependencies-only && time cabal build
      real    0m59.459s
      user    0m57.862s
      sys     0m1.185s
      $ cabal clean && time cabal build
      real    1m0.037s
      user    0m58.350s
      sys     0m1.199s
      $ cabal clean && time cabal build
      real    0m57.634s
      user    0m56.118s
      sys     0m1.202s
      $ cabal get text && cd text* && cabal sandbox init && cabal install
      --dependencies-only && time cabal build
      real    0m59.867s
      user    0m58.176s
      sys     0m1.188s
      $ cabal clean && time cabal build
      real    1m0.157s
      user    0m58.622s
      sys     0m1.177s
      $ cabal clean && time cabal build
      real    1m0.950s
      user    0m59.397s
      sys     0m1.083s
      ```
      
      Reviewers: ezyang, simonmar, austin, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1268
      
      GHC Trac Issues: #4012
      9cb192ce
    • Ben Gamari's avatar
      Add missing stderr file · 0499aa7c
      Ben Gamari authored
      0499aa7c
    • Moritz Kiefer's avatar
      Suggest enabling PatternSynonyms (#10943) · 1e8d1f1c
      Moritz Kiefer authored
      Suggest enabling PatternSynonyms if we find an invalid
      signature that looks like a pattern synonym.
      
      Reviewed By: austin, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1347
      1e8d1f1c
    • Ben Gamari's avatar
      Add another test for #10549 · c633f71f
      Ben Gamari authored
      c633f71f
  11. 21 Oct, 2015 1 commit
  12. 20 Oct, 2015 2 commits