1. 22 Feb, 2020 1 commit
  2. 12 Feb, 2020 1 commit
  3. 25 Jan, 2020 1 commit
  4. 22 Nov, 2018 1 commit
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
      
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
      
         Fix unused-import stuff in a better way
      
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      
      This led to Trac #13064 and #15393
      
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      
      The two important changes are
      
      * Fix the bug in bestImport
      
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      
      In unravalling this I also ended up doing a few other things
      
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      
      * Delete dead code RdrName.greUsedRdrName
      
      Bumps a few submodules.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5312
      6353efc7
  5. 06 Feb, 2018 1 commit
  6. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  7. 17 Jan, 2017 1 commit
  8. 09 Jul, 2015 1 commit
    • Ben Gamari's avatar
      Bitmap: Fix thunk explosion · b29633f5
      Ben Gamari authored
      Previously we would build up another `map (-N)` thunk
      for every word in the bitmap. Now we strictly accumulate the position
      and carry out a single ``map (`subtract` accum)``.
      
      `Bitmap.intsToBitmap` showed up in the profile while compiling a 
      testcase of #7450 (namely a program containing a record type with large 
      number of fields which derived `Read`). The culprit was 
      `CmmBuildInfoTables.procpointSRT.bitmap`. On the testcase (with 4096 
      fields), the profile previously looked like,
      
      ```
      	total time  =      307.94 secs   (307943 ticks @ 1000 us, 1 
      processor)
      	total alloc = 336,797,868,056 bytes  (excludes profiling 
      overheads)
      
      COST CENTRE              MODULE              %time %alloc
      
      lintAnnots               CoreLint             17.2   25.8
      procpointSRT.bitmap      CmmBuildInfoTables   11.3   25.2
      FloatOutwards            SimplCore             7.5    1.6
      flatten.lookup           CmmBuildInfoTables    4.0    3.9
      ...
      ```
      
      After this fix it looks like,
      ```
      	total time  =      256.88 secs   (256876 ticks @ 1000 us, 1 
      processor)
      	total alloc = 255,033,667,448 bytes  (excludes profiling 
      overheads)
      
      COST CENTRE              MODULE              %time %alloc
      
      lintAnnots               CoreLint             20.3   34.1
      FloatOutwards            SimplCore             9.1    2.1
      flatten.lookup           CmmBuildInfoTables    4.8    5.2
      pprNativeCode            AsmCodeGen            3.7    4.3
      simplLetUnfolding        Simplify              3.6    2.2
      StgCmm                   HscMain               3.6    2.1
      ```
      Signed-off-by: Ben Gamari's avatarBen Gamari <ben@smart-cactus.org>
      
      Test Plan: Validate
      
      Reviewers: austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1041
      
      GHC Trac Issues: #7450
      b29633f5
  9. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  10. 06 Apr, 2013 1 commit
  11. 18 Sep, 2012 1 commit
  12. 16 Sep, 2012 1 commit
  13. 14 Sep, 2012 1 commit
  14. 09 Jun, 2012 1 commit
  15. 04 Nov, 2011 1 commit
  16. 25 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      More refactoring (CgRep) · 493c12ff
      Simon Peyton Jones authored
      * Move CgRep (private to old codgen) from SMRep to ClosureInfo
      * Avoid using CgRep in new codegen
      * Move SMRep and Bitmap from codeGen/ to cmm/
      493c12ff
  17. 09 Dec, 2008 1 commit
  18. 27 Feb, 2008 1 commit
  19. 21 Sep, 2007 1 commit
  20. 04 Sep, 2007 1 commit
  21. 03 Sep, 2007 1 commit
  22. 01 Sep, 2007 1 commit
  23. 08 Jun, 2007 1 commit
  24. 11 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Module header tidyup, phase 1 · 49c98d14
      Simon Marlow authored
      This patch is a start on removing import lists and generally tidying
      up the top of each module.  In addition to removing import lists:
      
         - Change DATA.IOREF -> Data.IORef etc.
         - Change List -> Data.List etc.
         - Remove $Id$
         - Update copyrights
         - Re-order imports to put non-GHC imports last
         - Remove some unused and duplicate imports
      49c98d14
  25. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  26. 31 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-31 10:16:33 by simonmar] · 853e20a3
      simonmar authored
      Tweaks to get the GHC sources through Haddock.  Doesn't quite work
      yet, because Haddock complains about the recursive modules.  Haddock
      needs to understand SOURCE imports (it can probably just ignore them
      as a first attempt).
      853e20a3
  27. 19 May, 2003 1 commit
  28. 14 May, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-05-14 09:13:52 by simonmar] · 7a236a56
      simonmar authored
      Change the way SRTs are represented:
      
      Previously, the SRT associated with a function or thunk would be a
      sub-list of the enclosing top-level function's SRT.  But this approach
      can lead to lots of duplication: if a CAF is referenced in several
      different thunks, then it may appear several times in the SRT.
      Let-no-escapes compound the problem, because the occurrence of a
      let-no-escape-bound variable would expand to all the CAFs referred to
      by the let-no-escape.
      
      The new way is to describe the SRT associated with a function or thunk
      as a (pointer+offset,bitmap) pair, where the pointer+offset points
      into some SRT table (the enclosing function's SRT), and the bitmap
      indicates which entries in this table are "live" for this closure.
      The bitmap is stored in the 16 bits previously used for the length
      field, but this rarely overflows.  When it does overflow, we store the
      bitmap externally in a new "SRT descriptor".
      
      Now the enclosing SRT can be a set, hence eliminating the duplicates.
      
      Also, we now have one SRT per top-level function in a recursive group,
      where previously we used to have one SRT for the whole group.  This
      helps keep the size of SRTs down.
      
      Bottom line: very little difference most of the time.  GHC itself got
      slightly smaller.  One bad case of a module in GHC which had a huge
      SRT has gone away.
      
      While I was in the area:
      
        - Several parts of the back-end require bitmaps.  Functions for
          creating bitmaps are now centralised in the Bitmap module.
      
        - We were trying to be independent of word-size in a couple of
          places in the back end, but we've now abandoned that strategy so I
          simplified things a bit.
      7a236a56