1. 13 Jan, 2020 1 commit
  2. 08 Jan, 2020 1 commit
  3. 06 Jan, 2020 1 commit
  4. 20 Dec, 2019 1 commit
    • Ryan Scott's avatar
      lookupBindGroupOcc: recommend names in the same namespace (#17593) · 70e56b27
      Ryan Scott authored
      Previously, `lookupBindGroupOcc`'s error message would recommend all
      similar names in scope, regardless of whether they were type
      constructors, data constructors, or functions, leading to the
      confusion witnessed in #17593. This is easily fixed by only
      recommending names in the same namespace, using the
      `nameSpacesRelated` function.
      
      Fixes #17593.
      70e56b27
  5. 28 Nov, 2019 1 commit
  6. 27 Nov, 2019 1 commit
    • Vladislav Zavialov's avatar
      Whitespace-sensitive bang patterns (#1087, #17162) · 8168b42a
      Vladislav Zavialov authored
      This patch implements a part of GHC Proposal #229 that covers five
      operators:
      
      * the bang operator (!)
      * the tilde operator (~)
      * the at operator (@)
      * the dollar operator ($)
      * the double dollar operator ($$)
      
      Based on surrounding whitespace, these operators are disambiguated into
      bang patterns, lazy patterns, strictness annotations, type
      applications, splices, and typed splices.
      
      This patch doesn't cover the (-) operator or the -Woperator-whitespace
      warning, which are left as future work.
      8168b42a
  7. 01 Oct, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Refactor iface file generation: · f3cb8c7c
      Ömer Sinan Ağacan authored
      This commit refactors interface file generation to allow information
      from the later passed (NCG, STG) to be stored in interface files.
      
      We achieve this by splitting interface file generation into two parts:
      * Partial interfaces, built based on the result of the core pipeline
      * A fully instantiated interface, which also contains the final
      fingerprints and can optionally contain information produced by the backend.
      
      This change is required by !1304 and !1530.
      
      -dynamic-too handling is refactored too: previously when generating code
      we'd branch on -dynamic-too *before* code generation, but now we do it
      after.
      
      (Original code written by @AndreasK in !1530)
      
      Performance
      ~~~~~~~~~~~
      
      Before this patch interface files where created and immediately flushed
      to disk which made space leaks impossible.
      With this change we instead use NFData to force all iface related data
      structures to avoid space leaks.
      
      In the process of refactoring it was discovered that the code in the
      ToIface Module allocated a lot of thunks which were immediately forced
      when writing/forcing the interface file. So we made this module more
      strict to avoid creating many of those thunks.
      
      Bottom line is that allocations go down by about ~0.1% compared to
      master.
      Residency is not meaningfully different after this patch.
      Runtime was not benchmarked.
      Co-Authored-By: Andreas Klebinger's avatarAndreas Klebinger <klebinger.andreas@gmx.at>
      Co-Authored-By: Ömer Sinan Ağacan's avatarÖmer Sinan Ağacan <omer@well-typed.com>
      f3cb8c7c
  8. 20 Sep, 2019 1 commit
  9. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  10. 09 Jun, 2019 1 commit
  11. 30 Apr, 2019 6 commits
  12. 15 Mar, 2019 1 commit
  13. 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
  14. 04 Oct, 2018 1 commit
    • Alec Theriault's avatar
      Improve generated `GHC.Prim` docs · feb8a671
      Alec Theriault authored
      Summary:
      * Extended `genprimcode` to generate Haddock-compatible deprecations,
        as well as displaying information about which functions are LLVM-only
        and which functions can fail with an unchecked exception.
      
      * Ported existing deprecations to the new format, and also added a
        deprecation on `par#` (see Trac #15227).
      
      * Emit an error on fixity/deprecation of builtins, unless we are
        processing the module in which that name is defined (see Trac #15233).
        That means the following is no longer accepted (outside of `GHC.Types`):
      
      ```
      infixr 7 :
      {-# DEPRECATED (:) "cons is deprecated" #-}
      ```
      
      * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This
        means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in
        `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac
        #4861)
      
      as well as some misc fixes along the way.
      
      Reviewers: bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15227, #15233, #4861
      
      Differential Revision: https://phabricator.haskell.org/D5167
      feb8a671
  15. 25 Sep, 2018 1 commit
  16. 16 Jul, 2018 1 commit
    • Vladislav Zavialov's avatar
      Do not imply NoStarIsType by TypeOperators/TypeInType · 65c186f0
      Vladislav Zavialov authored
      Implementation of the "Embrace TypeInType" proposal was done according
      to the spec, which specified that TypeOperators must imply NoStarIsType.
      This implication was meant to prevent breakage and to be removed in 2
      releases.  However, compiling head.hackage has shown that this
      implication only magnified the breakage, so there is no reason to have
      it in the first place.
      
      To remain in compliance with the three-release policy, we add a
      workaround to define the (*) type operator even when -XStarIsType is on.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, RyanGlScott, goldfire, phadej, hvr
      
      Reviewed By: bgamari, RyanGlScott
      
      Subscribers: harpocrates, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4865
      65c186f0
  17. 15 Jun, 2018 1 commit
  18. 14 Jun, 2018 1 commit
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      Summary:
      Implement the "Embrace Type :: Type" GHC proposal,
      .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst
      
      GHC 8.0 included a major change to GHC's type system: the Type :: Type
      axiom. Though casual users were protected from this by hiding its
      features behind the -XTypeInType extension, all programs written in GHC
      8+ have the axiom behind the scenes. In order to preserve backward
      compatibility, various legacy features were left unchanged. For example,
      with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
      Now these restrictions are lifted and -XTypeInType becomes a redundant
      flag that will be eventually deprecated.
      
      * Incorporate the features currently in -XTypeInType into the
        -XPolyKinds and -XDataKinds extensions.
      * Introduce a new extension -XStarIsType to control how to parse * in
        code and whether to print it in error messages.
      
      Test Plan: Validate
      
      Reviewers: goldfire, hvr, bgamari, alanz, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15195
      
      Differential Revision: https://phabricator.haskell.org/D4748
      d650729f
  19. 24 May, 2018 1 commit
    • Ryan Scott's avatar
      Check for mismatched class methods during typechecking · 1879d9d2
      Ryan Scott authored
      Summary:
      Template Haskell provides a wormhole through which you can
      sneak methods that don't belong to a class into an instance for that
      class, bypassing the renamer's validity checks. The solution adopted
      here is to mirror the treatment for associated type family instances,
      which have an additional check in the typechecker which catch
      mismatched associated type families that were snuck through using
      Template Haskell. I've put a similar check for class methods into
      `tcMethods`.
      
      Test Plan: make test TEST=T12387
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #12387
      
      Differential Revision: https://phabricator.haskell.org/D4710
      1879d9d2
  20. 09 Apr, 2018 1 commit
  21. 12 Mar, 2018 1 commit
  22. 19 Dec, 2017 1 commit
  23. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      
      Reverts haddock submodule.
      
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
      314bc314
  24. 11 Nov, 2017 1 commit
  25. 11 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Tidy up some convoluted "child/parent" code · 7720c293
      Simon Peyton Jones authored
      In investigating something else (Trac #14307) I encountered the
      wonders of TcRnExports.lookupChildrenExport, and the data
      type ChildLookupResult.
      
      I managed to remove the NameErr constructor from ChildLookupResult,
      and simplify the code significantly at the same time.
      
      This is just refactoring; no change in behaviour.
      7720c293
  26. 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
  27. 07 Sep, 2017 1 commit
  28. 31 Aug, 2017 1 commit
  29. 26 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13968 by consulting isBuiltInOcc_maybe · d774b4e2
      Ryan Scott authored
      Summary:
      We were unconditionally reporting `Illegal binding of built-in syntax`
      in an error message, but this error doesn't make sense in certain Template
      Haskell scenarios which can trigger it. Let's give a more sensible error
      message by first checking if the name we're binding really is built-in syntax,
      using the handy `isBuiltInOcc_maybe` function.
      
      Test Plan: make test TEST=T13968
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13968
      
      Differential Revision: https://phabricator.haskell.org/D3789
      d774b4e2
  30. 11 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13948 by being pickier about when to suggest DataKinds · ba46e63f
      Ryan Scott authored
      Commit 343cb32d (#13568) made GHC a bit
      too cavalier in suggesting when data constructors are in scope (and
      suggesting the use of `DataKinds`). This tones down the suggestions so
      that `DataKinds` is only suggested if a data constructor of that name is
      actually in scope (previously, it would always suggest, even if it was
      out of scope).
      
      Fixes #13948.
      
      Test Plan: ./validate
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13948
      
      Differential Revision: https://phabricator.haskell.org/D3719
      ba46e63f
  31. 05 Jun, 2017 1 commit
    • Alan Zimmerman's avatar
      Udate hsSyn AST to use Trees that Grow · 8e6ec0fa
      Alan Zimmerman authored
      Summary:
      See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
      
      This commit prepares the ground for a full extensible AST, by replacing the type
      parameter for the hsSyn data types with a set of indices into type families,
      
          data GhcPs -- ^ Index for GHC parser output
          data GhcRn -- ^ Index for GHC renamer output
          data GhcTc -- ^ Index for GHC typechecker output
      
      These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
      
      Where the original name type is required in a polymorphic context, this is
      accessible via the IdP type family, defined as
      
          type family IdP p
          type instance IdP GhcPs = RdrName
          type instance IdP GhcRn = Name
          type instance IdP GhcTc = Id
      
      These types are declared in the new 'hsSyn/HsExtension.hs' module.
      
      To gain a better understanding of the extension mechanism, it has been applied
      to `HsLit` only, also replacing the `SourceText` fields in them with extension
      types.
      
      To preserve extension generality, a type class is introduced to capture the
      `SourceText` interface, which must be honoured by all of the extension points
      which originally had a `SourceText`.  The class is defined as
      
          class HasSourceText a where
            -- Provide setters to mimic existing constructors
            noSourceText  :: a
            sourceText    :: String -> a
      
            setSourceText :: SourceText -> a
            getSourceText :: a -> SourceText
      
      And the constraint is captured in `SourceTextX`, which is a constraint type
      listing all the extension points that make use of the class.
      
      Updating Haddock submodule to match.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
      
      Subscribers: rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3609
      8e6ec0fa
  32. 11 May, 2017 2 commits
    • Matthew Pickering's avatar
      RnEnv refactoring · a3873e8c
      Matthew Pickering authored
      Summary: Lots of refactoring in RnEnv to reduce code duplication.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13545
      
      Differential Revision: https://phabricator.haskell.org/D3507
      a3873e8c
    • mrkgnao's avatar
      Fix incorrect ambiguity error on identically-named data constructors · 1381c142
      mrkgnao authored
      Given multiple in-scope constructors with the same name, say `A`, and a
      function of type `A -> Int`, say, the compiler reports both a "type `A`
      is not in scope" and (incorrectly) an ambiguity error. The latter
      shouldn't be there if `DataKinds` isn't enabled.
      
      This issue was recommended to me by @mpickering as a suitable first
      task, and the fix was also outlined in the original Trac ticket. It
      involved a simple reordering of the steps taken in `lookup_demoted` in
      `RnEnv.hs`. The fix is to make the `DataKinds` check happen earlier,
      ensuring that the ambiguity check doesn't happen at all if we know the
      constructors couldn't have been promoted.
      Signed-off-by: mrkgnao's avatarSoham Chowdhury <chow.soham@gmail.com>
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13568
      
      Differential Revision: https://phabricator.haskell.org/D3547
      1381c142
  33. 02 May, 2017 1 commit
  34. 12 Apr, 2017 1 commit