1. 07 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix utterly bogus TagToEnum rule in caseRules · 4aa98f4a
      Simon Peyton Jones authored
      In prelRules we had:
      
        tx_con_tte :: DynFlags -> AltCon -> AltCon
        tx_con_tte _      DEFAULT      = DEFAULT
        tx_con_tte dflags (DataAlt dc)
          | tag == 0  = DEFAULT   -- See Note [caseRules for tagToEnum]
          | otherwise = LitAlt (mkMachInt dflags (toInteger tag))
      
      The tag==0 case is totally wrong, and led directly to Trac #14768.
      
      See "Beware" in Note [caseRules for tagToEnum] (in the patch).
      
      Easily fixed, though!
      4aa98f4a
  2. 03 Feb, 2018 1 commit
    • Ryan Scott's avatar
      Don't apply dataToTag's caseRules for data families · d8a0e6d3
      Ryan Scott authored
      Commit 193664d4 added a
      special caseRule for `dataToTag`, but this transformation completely
      broke when `dataToTag` was applied to somewith with a type headed by
      a data family, leading to #14680. For now at least, the simplest
      solution is to simply not apply this transformation when the type is
      headed by a data family.
      
      Test Plan: make test TEST=T14680
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14680
      
      Differential Revision: https://phabricator.haskell.org/D4371
      d8a0e6d3
  3. 19 Dec, 2017 1 commit
  4. 03 Oct, 2017 1 commit
  5. 26 Sep, 2017 2 commits
  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. 09 Sep, 2017 2 commits
    • Herbert Valerio Riedel's avatar
      Canonicalise MonoidFail instances in GHC · 346e562a
      Herbert Valerio Riedel authored
      IOW, code compiles -Wnoncanonical-monoidfail-instances clean now
      
      This is easy now since we require GHC 8.0/base-4.9 or later
      for bootstrapping.
      
      Note that we can easily enable `MonadFail` via
      
        default-extensions: MonadFailDesugaring
      
      in compiler/ghc.cabal.in
      
      which currently would point out that NatM doesn't have
      a proper `fail` method, even though failable patterns
      are made use of:
      
        compiler/nativeGen/SPARC/CodeGen.hs:425:25: error:
          * No instance for (Control.Monad.Fail.MonadFail NatM)
              arising from a do statement
              with the failable pattern ‘(dyn_c, [dyn_r])’
      346e562a
    • Herbert Valerio Riedel's avatar
      Remove now redundant CPP · cf6b4d1c
      Herbert Valerio Riedel authored
      Resulting from requiring to boot with GHC 8.0 or later
      cf6b4d1c
  8. 01 Sep, 2017 1 commit
  9. 31 Jul, 2017 1 commit
  10. 28 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Re-engineer caseRules to add tagToEnum/dataToTag · 193664d4
      Simon Peyton Jones authored
      See Note [Scrutinee Constant Folding] in SimplUtils
      
      * Add cases for tagToEnum and dataToTag. This is the main new
        bit.  It allows the simplifier to remove the pervasive uses
        of     case tagToEnum (a > b) of
                  False -> e1
                  True  -> e2
        and replace it by the simpler
               case a > b of
                  DEFAULT -> e1
                  1#      -> e2
        See Note [caseRules for tagToEnum]
        and Note [caseRules for dataToTag] in PrelRules.
      
      * This required some changes to the API of caseRules, and hence
        to code in SimplUtils.  See Note [Scrutinee Constant Folding]
        in SimplUtils.
      
      * Avoid duplication of work in the (unusual) case of
           case BIG + 3# of b
             DEFAULT -> e1
             6#      -> e2
      
        Previously we got
           case BIG of
             DEFAULT -> let b = BIG + 3# in e1
             3#      -> let b = 6#       in e2
      
        Now we get
           case BIG of b#
             DEFAULT -> let b = b' + 3# in e1
             3#      -> let b = 6#      in e2
      
      * Avoid duplicated code in caseRules
      
      A knock-on refactoring:
      
      * Move Note [Word/Int underflow/overflow] to Literal, as
        documentation to accompany mkMachIntWrap etc; and get
        rid of PrelRuls.intResult' in favour of mkMachIntWrap
      193664d4
  11. 17 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      No join-point from an INLINE function with wrong arity · a7dbafe9
      Simon Peyton Jones authored
      The main payload of this patch is NOT to make a join-point
      from a function with an INLINE pragma and the wrong arity;
      see Note [Join points and INLINE pragmas] in CoreOpt.
      This is what caused Trac #13413.
      
      But we must do the exact same thing in simpleOptExpr,
      which drove me to the following refactoring:
      
      * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new
        module CoreOpt along with a few others (exprIsConApp_maybe,
        pushCoArg, etc)
      
        This eliminates a module loop altogether (delete
        CoreArity.hs-boot), and stops CoreSubst getting too huge.
      
      * Rename Simplify.matchOrConvertToJoinPoint
           to joinPointBinding_maybe
        Move it to the new CoreOpt
        Use it in simpleOptExpr as well as in Simplify
      
      * Define CoreArity.joinRhsArity and use it
      a7dbafe9
  12. 24 Jan, 2017 1 commit
  13. 20 Jan, 2017 1 commit
    • takano-akio's avatar
      Allow top-level string literals in Core (#8472) · d49b2bb2
      takano-akio authored
      This commits relaxes the invariants of the Core syntax so that a
      top-level variable can be bound to a primitive string literal of type
      Addr#.
      
      This commit:
      
      * Relaxes the invatiants of the Core, and allows top-level bindings whose
        type is Addr# as long as their RHS is either a primitive string literal or
        another variable.
      
      * Allows the simplifier and the full-laziness transformer to float out
        primitive string literals to the top leve.
      
      * Introduces the new StgGenTopBinding type to accomodate top-level Addr#
        bindings.
      
      * Introduces a new type of labels in the object code, with the suffix "_bytes",
        for exported top-level Addr# bindings.
      
      * Makes some built-in rules more robust. This was necessary to keep them
        functional after the above changes.
      
      This is a continuation of D2554.
      
      Rebasing notes:
      This had two slightly suspicious performance regressions:
      
      * T12425: bytes allocated regressed by roughly 5%
      * T4029: bytes allocated regressed by a bit over 1%
      * T13035: bytes allocated regressed by a bit over 5%
      
      These deserve additional investigation.
      
      Rebased by: bgamari.
      
      Test Plan: ./validate --slow
      
      Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari
      
      Reviewed By: trofi, simonpj, bgamari
      
      Subscribers: trofi, simonpj, gridaphobe, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2605
      
      GHC Trac Issues: #8472
      d49b2bb2
  14. 09 Dec, 2016 1 commit
    • Sylvain Henry's avatar
      Scrutinee Constant Folding · d3b546b1
      Sylvain Henry authored
      This patch introduces new rules to perform constant folding through
      case-expressions.
      
      E.g.,
      ```
      case t -# 10# of _ {  ===> case t of _ {
               5#      -> e1              15#     -> e1
               8#      -> e2              18#     -> e2
               DEFAULT -> e               DEFAULT -> e
      ```
      
      The initial motivation is that it allows "Merge Nested Cases"
      optimization to kick in and to further simplify the code
      (see Trac #12877).
      
      Currently we recognize the following operations for Word# and Int#: Add,
      Sub, Xor, Not and Negate (for Int# only).
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2762
      
      GHC Trac Issues: #12877
      d3b546b1
  15. 05 Sep, 2016 1 commit
  16. 20 Mar, 2016 1 commit
  17. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  18. 01 Jan, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Canonicalise `MonadPlus` instances · dafeb51f
      Herbert Valerio Riedel authored
      This refactoring exploits the fact that since AMP, in most cases,
      `instance MonadPlus` can be automatically derived from the respective
      `Alternative` instance.  This is because `MonadPlus`'s default method
      implementations are fully defined in terms of `Alternative(empty, (<>))`.
      dafeb51f
  19. 31 Dec, 2015 2 commits
  20. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  21. 17 Nov, 2015 1 commit
    • quchen's avatar
      MonadFail proposal, phase 1 · 233d1312
      quchen authored
      This implements phase 1 of the MonadFail proposal (MFP, #10751).
      
      - MonadFail warnings are all issued as desired, tunable with two new flags
      - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings`
        (but it's disabled by default right now)
      
      Credits/thanks to
      - Franz Thoma, whose help was crucial to implementing this
      - My employer TNG Technology Consulting GmbH for partially funding us
        for this work
      
      Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma
      
      Reviewed By: hvr, bgamari, fmthoma
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1248
      
      GHC Trac Issues: #10751
      233d1312
  22. 17 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make Monad/Applicative instances MRP-friendly · e8ed2136
      Herbert Valerio Riedel authored
      This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
      such that the explicit definitions for `return` and `(>>)` match the
      MRP-style default-implementation, i.e.
      
        return = pure
      
      and
      
        (>>) = (*>)
      
      This way, e.g. all `return = pure` definitions can easily be grepped and
      removed in GHC 8.1;
      
      Test Plan: Harbormaster
      
      Reviewers: goldfire, alanz, bgamari, quchen, austin
      
      Reviewed By: quchen, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1312
      e8ed2136
  23. 02 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Fix treatment of -0.0 · eb975d2e
      Ben Gamari authored
      Here we fix a few mis-optimizations that could occur in code with
      floating point comparisons with -0.0. These issues arose from our
      insistence on rewriting equalities into case analyses and the
      simplifier's ignorance of floating-point semantics.
      
      For instance, in Trac #10215 (and the similar issue Trac #9238) we
      turned `ds == 0.0` into a case analysis,
      
      ```
      case ds of
          __DEFAULT -> ...
          0.0 -> ...
      ```
      
      Where the second alternative matches where `ds` is +0.0 and *also* -0.0.
      However, the simplifier doesn't realize this and will introduce a local
      inlining of `ds = -- +0.0` as it believes this is the only
      value that matches this pattern.
      
      Instead of teaching the simplifier about floating-point semantics
      we simply prohibit case analysis on floating-point scrutinees and keep
      this logic in the comparison primops, where it belongs.
      
      We do several things here,
      
       - Add test cases from relevant tickets
       - Clean up a bit of documentation
       - Desugar literal matches against floats into applications of the
         appropriate equality primitive instead of case analysis
       - Add a CoreLint to ensure we don't pattern match on floats in Core
      
      Test Plan: validate with included testcases
      
      Reviewers: goldfire, simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1061
      
      GHC Trac Issues: #10215, #9238
      eb975d2e
  24. 23 Sep, 2015 1 commit
  25. 18 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
  26. 14 May, 2015 1 commit
    • Austin Seipp's avatar
      Revert multiple commits · 3cf8ecdc
      Austin Seipp authored
      This reverts multiple commits from Simon:
      
        - 04a484ea Test Trac #10359
        - a9ccd37a Test Trac #10403
        - c0aae6f6 Test Trac #10248
        - eb6ca851 Make the "matchable-given" check happen first
        - ca173aa3 Add a case to checkValidTyCon
        - 51cbad15 Update haddock submodule
        - 6e1174da Separate transCloVarSet from fixVarSet
        - a8493e03 Fix imports in HscMain (stage2)
        - a154944b Two wibbles to fix the build
        - 5910a1bc Change in capitalisation of error msg
        - 130e93aa Refactor tuple constraints
        - 8da785d5 Delete commented-out line
      
      These break the build by causing Haddock to fail mysteriously when
      trying to examine GHC.Prim it seems.
      3cf8ecdc
  27. 13 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
  28. 03 Mar, 2015 1 commit
  29. 10 Feb, 2015 1 commit
  30. 03 Dec, 2014 1 commit
  31. 19 Nov, 2014 1 commit
    • Luite Stegeman's avatar
      use correct word size for shiftRightLogical and removeOp32 · 4dd87c5e
      Luite Stegeman authored
      Summary:
      shiftRightLogical used a host sized Word for the intermediate value,
      which would produce the wrong result when cross compiling to a target
      with a different word size than the host.
      
      removeOp32 used the preprocessor to bake in word size assumptions,
      rather than getting the target word size from DynFlags
      
      Test Plan: validate
      
      Reviewers: hvr, rwbarton, carter, austin
      
      Reviewed By: austin
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D502
      
      GHC Trac Issues: #9736
      4dd87c5e
  32. 26 Sep, 2014 1 commit
  33. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      
      
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  34. 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
  35. 13 Mar, 2014 1 commit
  36. 12 Dec, 2013 1 commit
  37. 10 Oct, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Update and clean-up the implmenation of GHC.TypeLits · c3762fa4
      Iavor S. Diatchki authored
      * Replace class `SingI` with two separate classes: `KnownNat` and `KnownSymbol`
      
      * Rename `magicSingId` to `magicDictId`.
      
      * Simplify and clean-up the "magic" implementation.  This version makes
        a lot more sense, at least to me :-)
      
      * Update notes about how it all works:
      
        Note [KnownNat & KnownSymbol and EvLit] explains the evidence for the
        built-in classes
      
        Note [magicDictId magic] explains how we coerce singleton values into
        dictionaries.  This is used to turn run-time integers and strings into
        Proxy singletons of unknwon type (using an existential).
      c3762fa4