1. 11 Dec, 2015 4 commits
    • 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
    • Adam Gundry's avatar
      Fix infix record field fixity (#11167 and #11173). · 6e56ac58
      Adam Gundry authored
      This extends D1585 with proper support for infix duplicate record
      fields.  In particular, it is now possible to declare record fields as
      infix in a module for which `DuplicateRecordFields` is enabled, fixity
      is looked up correctly and a readable (although unpleasant) error
      message is generated if multiple fields with different fixities are in
      scope.
      
      As a bonus, `DEPRECATED` and `WARNING` pragmas now work for
      duplicate record fields. The pragma applies to all fields with the
      given label.
      
      In addition, a couple of minor `DuplicateRecordFields` bugs, which were
      pinpointed by the `T11167_ambig` test case, are fixed by this patch:
      
        - Ambiguous infix fields can now be disambiguated by putting a type
          signature on the first argument
      
        - Polymorphic type constructor signatures (such as `ContT () IO a` in
          `T11167_ambig`) now work for disambiguation
      
      Parts of this patch are from D1585 authored by @KaneTW.
      
      Test Plan: New tests added.
      
      Reviewers: KaneTW, bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1600
      
      GHC Trac Issues: #11167, #11173
      6e56ac58
    • kanetw's avatar
      Improved data family export documentation · b1382481
      kanetw authored
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1587
      
      GHC Trac Issues: #11164
      b1382481
    • Matthew Pickering's avatar
      Make sure PatSyns only get added once to tcg_patsyns · 41ef8f70
      Matthew Pickering authored
      Summary: Before, `PatSyn`s were getting added twice to `tcg_patsyns` so
      when inspecting afterwards there were duplicates in the list.
      This makes sure that only they only get added once.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1597
      41ef8f70
  2. 09 Dec, 2015 3 commits
    • Gabor Greif's avatar
      More typos in comments/docs · 688069ca
      Gabor Greif authored
      688069ca
    • Simon Peyton Jones's avatar
      Comments only · e9ea0209
      Simon Peyton Jones authored
      e9ea0209
    • Simon Peyton Jones's avatar
      Fix DeriveAnyClass (Trac #9968) · af77089b
      Simon Peyton Jones authored
      The main issue concerned things like
      
         data T a = MkT a deriving( C Int )
      
      which is supposed to generate
      
         instance C Int (T a) where {}
      
      But the 'Int' argument (called cls_tys in the code) wasn't
      even being passed to inferConstraints and mk_data_eqn, so it
      really had no chance.   DeriveAnyClass came along after this
      code was written!
      
      Anyway I did quite a bit of tidying up in inferConstraints.
      
      Also I discovered that this case was not covered at all
      
         data T a b = MkT a b deriving( Bifunctor )
      
      What constraints should we generate for the instance context?
      We can deal with classes whose last arg has kind *, like Eq, Ord;
      or (* -> *), like Functor, Traversable.  But we really don't have
      a story for classes whose last arg has kind (* -> * -> *).
      
      So I augmented checkSideConditions to check for that and give
      a sensible error message.
      
      ToDo: update the user manual.
      af77089b
  3. 08 Dec, 2015 7 commits
  4. 07 Dec, 2015 7 commits
    • Ömer Sinan Ağacan's avatar
      Get rid of tcView altogether · 834f9a46
      Ömer Sinan Ağacan authored
      This is just a trivial renaming that implements a ToDo mentioned in a comment
      in Type.hs.
      
      Adding Simon as reviewer since he added the ToDo comment.
      
      Reviewers: simonpj, austin, goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1584
      834f9a46
    • Herbert Valerio Riedel's avatar
      Re-use `transformers`'s `MaybeT` rather than our own · 09333313
      Herbert Valerio Riedel authored
      The now removed `MaybeT` type was originally added back in 2008
      via bc845b71
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1583
      09333313
    • Eric Seidel's avatar
      Move checking for missing signatures to RnNames.reportUnusedNames · 1bd40c86
      Eric Seidel authored
      Checking for missing signatures before renaming the export list is
      prone to errors, so we now perform the check in `reportUnusedNames` at
      which point everything has been renamed.
      
      Test Plan: validate, new test case is T10908
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1561
      
      GHC Trac Issues: #10908
      1bd40c86
    • Alan Zimmerman's avatar
      Refactor ConDecl · 51a5e68d
      Alan Zimmerman authored
      The ConDecl type in HsDecls is an uneasy compromise. For the most part,
      HsSyn directly reflects the syntax written by the programmer; and that
      gives just the right "pegs" on which to hang Alan's API annotations. But
      ConDecl doesn't properly reflect the syntax of Haskell-98 and GADT-style
      data type declarations.
      
      To be concrete, here's a draft new data type
      
      ```lang=hs
      data ConDecl name
        | ConDeclGADT
            { con_names   :: [Located name]
            , con_type    :: LHsSigType name  -- The type after the ‘::’
            , con_doc     :: Maybe LHsDocString }
      
        | ConDeclH98
            { con_name    :: Located name
      
            , con_qvars     :: Maybe (LHsQTyVars name)
              -- User-written forall (if any), and its implicit
              -- kind variables
              -- Non-Nothing needs -XExistentialQuantification
      
            , con_cxt       :: Maybe (LHsContext name)
              -- ^ User-written context (if any)
      
            , con_details   :: HsConDeclDetails name
                -- ^ Arguments
      
            , con_doc       :: Maybe LHsDocString
                -- ^ A possible Haddock comment.
            } deriving (Typeable)
      ```
      
      Note that
      
          For GADTs, just keep a type. That's what the user writes.
          NB:HsType can represent records on the LHS of an arrow:
      
            { x:Int,y:Bool} -> T
      
          con_qvars and con_cxt are both Maybe because they are both
          optional (the forall and the context of an existential data type
      
          For ConDeclGADT the type variables of the data type do not scope
          over the con_type; whereas for ConDeclH98 they do scope over con_cxt
          and con_details.
      
      Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, erikd, hvr, goldfire, austin, bgamari
      
      Subscribers: erikd, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1558
      
      GHC Trac Issues: #11028
      51a5e68d
    • Ryan Scott's avatar
      Use TypeLits in the meta-data encoding of GHC.Generics · 700c42b5
      Ryan Scott authored
      Test Plan: Validate.
      
      Reviewers: simonpj, goldfire, hvr, dreixel, kosmikus, austin, bgamari
      
      Reviewed By: kosmikus, austin, bgamari
      
      Subscribers: RyanGlScott, Fuuzetsu, bgamari, thomie, carter, dreixel
      
      Differential Revision: https://phabricator.haskell.org/D493
      
      GHC Trac Issues: #9766
      700c42b5
    • roshats's avatar
      Add isImport, isDecl, and isStmt functions to GHC API · 2110037e
      roshats authored
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1518
      
      GHC Trac Issues: #9015
      2110037e
    • kanetw's avatar
      Re-export data family when exporting a data instance without an export list · 8cef8af3
      kanetw authored
      Whenever a data instance is exported, the corresponding data family
      is exported, too. This allows one to write
      
      ```
           -- Foo.hs
           module Foo where
      
           data family T a
      
           -- Bar.hs
           module Bar where
      
           import Foo
      
           data instance T Int = MkT
      
           -- Baz.hs
           module Baz where
      
           import Bar (T(MkT))
      ```
      
      In previous versions of GHC, this required a workaround
      explicit export list in `Bar`.
      
      Reviewers: bgamari, goldfire, austin
      
      Reviewed By: bgamari, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1573
      
      GHC Trac Issues: #11164
      8cef8af3
  5. 06 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Implement new `-fwarn-noncanonical-monoid-instances` · 986ceb16
      Herbert Valerio Riedel authored
      This is similiar to the `-fwarn-noncanonical-monad-instances` warning
      implemented via #11128, but applies to `Semigroup`/`Monoid` instead
      and the `(<>)`/`mappend` methods (of which `mappend` is planned to move
      out of `Monoid` at some point in the future being redundant and thus
      error-prone).
      
      This warning is contained in `-Wcompat` but not in `-Wall`.
      
      This addresses #11150
      
      Reviewed By: quchen
      
      Differential Revision: https://phabricator.haskell.org/D1553
      986ceb16
  6. 05 Dec, 2015 2 commits
  7. 04 Dec, 2015 14 commits
    • Ömer Sinan Ağacan's avatar
      StgCmmMonad: Implement Outputable instance for Sequel for debugging · c865c425
      Ömer Sinan Ağacan authored
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1563
      c865c425
    • Simon Peyton Jones's avatar
      Comments only · 43a5970a
      Simon Peyton Jones authored
      43a5970a
    • Simon Peyton Jones's avatar
      Tidy user type errors in checkValidType · 67565a72
      Simon Peyton Jones authored
      Trac #11144 showed that we need to tidy the type in the error message
      generated in TcValidity.checkUserTypeError.
      
      This is still unsatisfactory.  checkValidType was originally supposed
      to be called only on types gotten directly from user-written HsTypes.
      So its error messages do no tidying.  But TcBinds calls it checkValidType
      on an /inferred/ type, which may need tidying.
      
      Still this at least fixes the bad error message in CustomTypeErrors02,
      which was the original ticket.
      
      Some other small refactorings:
      
      * Remove unused Kind result of getUserTypeErrorMsg
      * Rename isUserErrorTy  -->   userTypeError_maybe
      67565a72
    • Simon Peyton Jones's avatar
      Minor refactoring of user type errors · 31b482bf
      Simon Peyton Jones authored
      * Remove unused Kind result of getUserTypeErrorMsg
      * Rename isUserErrorTy  -->   userTypeError_maybe
      31b482bf
    • Simon Peyton Jones's avatar
      Fix egregious error in eta-reduction of data families · 1160dc51
      Simon Peyton Jones authored
      This terrible and long-standing bug was shown up by Trac #11148.
      We are trying to eta-reduce a data family instance, so that we
      can then derive Functor or Generic.  But we were assuming, for
      absolutely not reason whatsoever, that the type variables were
      lined up in a convenient order.  The fact that it ever worked
      was a fluke.
      
      This patch fixes it properly.  Main change is in eta_reduce
      in TcInstDcls.tcDataFamInstDecl
      1160dc51
    • Simon Peyton Jones's avatar
      Make -dppr-debug show contents of (TypeError ...) · 822141b9
      Simon Peyton Jones authored
      Just for debugging
      822141b9
    • Simon Peyton Jones's avatar
      Wibbles only · 1cb3c8c2
      Simon Peyton Jones authored
      1cb3c8c2
    • Simon Peyton Jones's avatar
      Add derived constraints for wildcard signatures · 28035c09
      Simon Peyton Jones authored
      This fixes Trac #11016
      
      See Note [Add deriveds for signature contexts] in TcSimplify]
      28035c09
    • Simon Peyton Jones's avatar
      Case-of-empty-alts is trivial (Trac #11155) · 1c9fd3f1
      Simon Peyton Jones authored
      As you'll see from Trac #11155, the code generator was confused
      by a binding let x = y in ....   Why did that happen? Because of
      a (case y of {}) expression on the RHS.
      
      The right thing is just to expand what a "trivial" expression is.
      
      See Note [Empty case is trivial] in CoreUtils.
      1c9fd3f1
    • Bartosz Nitka's avatar
      Make callToPats deterministic in SpecConstr · 5b2b7e33
      Bartosz Nitka authored
      This fixes a non-determinism bug where where depending on the
      order of uniques allocated, the specialized workers would have different
      order of arguments.
      
      Compare:
      
      ```
        $s$wgo_s1CN :: Int# -> Int -> Int#
        [LclId, Arity=2, Str=DmdType <L,U><L,U>]
        $s$wgo_s1CN =
          \ (sc_s1CI :: Int#) (sc_s1CJ :: Int) ->
            case tagToEnum# @ Bool (<=# sc_s1CI 0#) of _ [Occ=Dead] {
              False ->
                $wgo_s1BU (Just @ Int (I# (-# sc_s1CI 1#))) (Just @ Int sc_s1CJ);
              True -> 0#
            }
      ```
      
      vs
      
      ```
        $s$wgo_s18mTj :: Int -> Int# -> Int#
        [LclId, Arity=2, Str=DmdType <L,U><L,U>]
        $s$wgo_s18mTj =
          \ (sc_s18mTn :: Int) (sc_s18mTo :: Int#) ->
            case tagToEnum# @ Bool (<=# sc_s18mTo 0#) of _ [Occ=Dead] {
              False ->
                $wgo_s18mUc
                  (Just @ Int (I# (-# sc_s18mTo 1#))) (Just @ Int sc_s18mTn);
              True -> 0#
            }
      ```
      
      Test Plan:
      I've added a new testcase
      ./validate
      
      Reviewers: simonmar, simonpj, austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1508
      
      GHC Trac Issues: #4012
      5b2b7e33
    • Ben Gamari's avatar
      Check: More Clang/CPP wibbles · befc4e4c
      Ben Gamari authored
      befc4e4c
    • Ben Gamari's avatar
      PmExpr: Fix CPP unacceptable too clang's CPP · d40f5b78
      Ben Gamari authored
      d40f5b78
    • Georgios Karachalias's avatar
      99d01e1d
    • Georgios Karachalias's avatar
      Improve performance for PM check on literals (Fixes #11160 and #11161) · ae4398d6
      Georgios Karachalias authored
      Two changes:
      
      1. Instead of generating constraints of the form (x ~ e) (as we do in
      the paper), generate constraints of the form (e ~ e). The term oracle
      (`tmOracle` in deSugar/TmOracle.hs) is not really efficient and in the
      presence of many (x ~ e) constraints behaves quadratically. For
      literals, constraints of the form (False ~ (x ~ lit)) are pretty common,
      so if we start with { y ~ False, y ~ (x ~ lit) } we end up givng to the
      solver (a) twice as many constraints as we need and (b) half of them
      trigger the solver's weakness. This fixes #11160.
      
      2. Treat two overloaded literals that look different as different. This
      is not entirely correct but it is what both the previous and the current
      check did. I had the ambitious plan to do the *right thing* (equality
      between overloaded literals is undecidable in the general case) and just
      use this assumption when issuing the warnings. It seems to generate much
      more constraints than I expected (breaks #11161) so I just do it
      immediately now instead of generating everything and filtering
      afterwards.
      
      Even if it is not (strictly speaking) correct, we have the following:
        * Gives the "expected" warnings (the ones Ocaml or the previous
          algorithm would give) and,
        * Most importantly, it is safe. Unless a catch-all clause exists, a
          match against literals is always non-exhaustive. So, effectively
          this affects only what is shown to the user (and, evidently,
          performance!).
      ae4398d6
  8. 03 Dec, 2015 2 commits