1. 01 Dec, 2015 2 commits
    • Gabor Greif's avatar
      Fix warning about unused pattern variable · 44c3e376
      Gabor Greif authored
      44c3e376
    • thomie's avatar
      Build system: Add stage specific SRC_HC_(WARNING_)OPTS · 14d0f7f1
      thomie authored
      * Add stage specific versions of SRC_HC_OPTS. These are currently only
        used for -Werror. The previous combination of GhcStage2HcOpts and
        GhcLibHcOpts didn't apply to utils/*.
      
      * Add stage specific versions of SRC_HC_WARNING_OPTS. These will later be
        used for new warning supression flags that should not be passed to the
        bootstrap compiler.
      
      * Move -Wall (and -Werror) related code back to mk/warnings.mk, where it
        was before 987d5427. Now all warning related code is nicely together.
        Include mk/warnings.mk after mk/custom-settings.mk to make this work.
      
      Reviewed By: bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1536
      14d0f7f1
  2. 29 Nov, 2015 3 commits
    • quchen's avatar
      Implement warnings for Semigroups as parent of Monoid · 290def72
      quchen authored
      This patch is similar to the AMP patch (#8004), which offered two
      functions:
      
        1. Warn when an instance of a class has been given, but the type does
           not have a certain superclass instance
        2. Warn when top-level definitions conflict with future Prelude names
      
      These warnings are issued as part of the new `-Wcompat` warning group.
      
      Reviewers: hvr, ekmett, austin, bgamari
      
      Reviewed By: hvr, ekmett, bgamari
      
      Subscribers: ekmett, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1539
      
      GHC Trac Issues: #11139
      290def72
    • Adam Sandberg Eriksson's avatar
      ghc-pkg: print version when verbose · 55c737fd
      Adam Sandberg Eriksson authored
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1534
      55c737fd
    • Herbert Valerio Riedel's avatar
      Implement new -XTemplateHaskellQuotes pragma · 85fcd035
      Herbert Valerio Riedel authored
      Since f16ddcee / D876, `ghc-stage1`
      supports a subset of `-XTemplateHaskell`, but since we need Cabal to be
      able detect (so `.cabal` files can be specified accordingly, see also
      GHC #11102 which omits `TemplateHaskell` from `--supported-extensions`)
      whether GHC provides full or only partial `-XTemplateHaskell` support,
      the proper way to accomplish this is to split off the
      quotation/non-splicing `TemplateHaskell` feature-subset into a new
      language pragma `TemplateHaskellQuotes`.
      
      Moreover, `-XTemplateHaskellQuotes` is considered safe under SafeHaskell
      
      This addresses #11121
      
      Reviewers: goldfire, ezyang, dterei, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1511
      
      GHC Trac Issues: #11121
      85fcd035
  3. 24 Nov, 2015 3 commits
    • Ben Gamari's avatar
      Rewrite checkUniques and incorporate into validate · e506f02d
      Ben Gamari authored
      This should catch duplicate uniques in the future before Bad Things
      happen.
      
      Test Plan: Introduce a duplicate unique and validate
      
      Reviewers: austin, hvr, thomie
      
      Reviewed By: hvr, thomie
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1521
      e506f02d
    • quchen's avatar
      Add -Wcompat warning flag group · 6d147939
      quchen authored
      Reviewers: hvr, austin, thomie, bgamari
      
      Reviewed By: hvr, austin, thomie, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1495
      
      GHC Trac Issues: #11000
      6d147939
    • Herbert Valerio Riedel's avatar
      Implement new `-fwarn-noncanonical-monad-instances` · f09f2470
      Herbert Valerio Riedel authored
      Warn about incoherent/non-canonical 'Applicative'/'Monad' instance
      declarations. Specifically the following invariants are checked:
      
      In 'Monad' instances declarations warn if the any of the following
      conditions does not hold:
      
       * If `return` is overridden it must be canonical (i.e. `return = pure`).
       * If `(>>)` is overridden it must be canonical (i.e. `(>>) = (*>)`).
      
      In 'Applicative' instance declarations:
      
       * Warn if 'pure' is defined backwards (i.e. `pure = return`).
       * Warn if '(*>)' is defined backwards (i.e. `(*>) = (>>)`).
      
      NB, this warning flag is not enabled via `-Wall` nor `-Wcompat`.
      
      This addresses #11128
      
      Reviewers: quchen, austin, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1516
      f09f2470
  4. 23 Nov, 2015 1 commit
  5. 22 Nov, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations: Make all RdrName occurences Located · 3df9563e
      Alan Zimmerman authored
      At the moment the API Annotations can only be used on the ParsedSource,
      as there are changes made to the RenamedSource that prevent it from
      being used to round trip source code.
      
      It is possible to build a map from every Located Name in the
      RenamedSource from its location to the Name, which can then be used when
      resolved names are required when changing the ParsedSource.
      
      However, there are instances where the identifier is not located,
      specifically
      
        (GHC.VarPat name)
        (GHC.HsVar name)
        (GHC.UserTyVar name)
        (GHC.HsTyVar name)
      
      Replace each of the name types above with (Located name)
      
      Updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1512
      
      GHC Trac Issues: #11019
      3df9563e
  6. 19 Nov, 2015 2 commits
  7. 18 Nov, 2015 2 commits
  8. 16 Nov, 2015 1 commit
  9. 12 Nov, 2015 1 commit
    • olsner's avatar
      Implement function-sections for Haskell code, #8405 · 4a32bf92
      olsner authored
      This adds a flag -split-sections that does similar things to
      -split-objs, but using sections in single object files instead of
      relying on the Satanic Splitter and other abominations. This is very
      similar to the GCC flags -ffunction-sections and -fdata-sections.
      
      The --gc-sections linker flag, which allows unused sections to actually
      be removed, is added to all link commands (if the linker supports it) so
      that space savings from having base compiled with sections can be
      realized.
      
      Supported both in LLVM and the native code-gen, in theory for all
      architectures, but really tested on x86 only.
      
      In the GHC build, a new SplitSections variable enables -split-sections
      for relevant parts of the build.
      
      Test Plan: validate with both settings of SplitSections
      
      Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari
      
      Reviewed By: simonmar, thomie, bgamari
      
      Subscribers: hsyl20, erikd, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1242
      
      GHC Trac Issues: #8405
      4a32bf92
  10. 11 Nov, 2015 2 commits
  11. 07 Nov, 2015 1 commit
  12. 02 Nov, 2015 1 commit
  13. 01 Nov, 2015 4 commits
  14. 31 Oct, 2015 2 commits
  15. 30 Oct, 2015 4 commits
    • 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
      Build system: cabalise deriveConstants + genprimopcode · 314395e0
      thomie authored
      This is needed for #10374 (but doesn't fix it yet).
      
      Also rename DeriveConstants.hs to Main.hs, because the build
      system has trouble with Main modules not called Main.hs.
      
      Differential Revision: https://phabricator.haskell.org/D1380
      314395e0
    • thomie's avatar
      Build system: cleanup a few .cabal files · b05ab1a8
      thomie authored
      b05ab1a8
    • thomie's avatar
      Build system: rename runghc.hs to Main.hs · 1f1c7c61
      thomie authored
      The build system has trouble with Main modules not called Main.hs. This
      change allows a hack in utils/runghc/ghc.mk to be removed.
      1f1c7c61
  16. 29 Oct, 2015 2 commits
    • 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
  17. 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
  18. 27 Oct, 2015 1 commit
  19. 26 Oct, 2015 1 commit
  20. 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
  21. 18 Oct, 2015 1 commit
  22. 16 Oct, 2015 1 commit
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      This implements DuplicateRecordFields, the first part of the
      OverloadedRecordFields extension, as described at
      https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
      
      This includes fairly wide-ranging changes in order to allow multiple
      records within the same module to use the same field names.  Note that
      it does *not* allow record selector functions to be used if they are
      ambiguous, and it does not have any form of type-based disambiguation
      for selectors (but it does for updates). Subsequent parts will make
      overloading selectors possible using orthogonal extensions, as
      described on the wiki pages.  This part touches quite a lot of the
      codebase, and requires changes to several GHC API datatypes in order
      to distinguish between field labels (which may be overloaded) and
      selector function names (which are always unique).
      
      The Haddock submodule has been adapted to compile with the GHC API
      changes, but it will need further work to properly support modules
      that use the DuplicateRecordFields extension.
      
      Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
      will be extended once the other parts are implemented.
      
      Reviewers: goldfire, bgamari, simonpj, austin
      
      Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
      goldfire
      
      Differential Revision: https://phabricator.haskell.org/D761
      b1884b0e
  23. 15 Oct, 2015 2 commits