1. 12 Sep, 2017 1 commit
  2. 27 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
  3. 11 Jul, 2017 1 commit
    • Ömer Sinan Ağacan's avatar
      Mention which -Werror promoted a warning to an error · 4befb415
      Ömer Sinan Ağacan authored
      Previously -Werror or -Werror=flag printed warnings as usual and then
      printed
      these two lines:
      
          <no location info>: error:
          Failing due to -Werror.
      
      This is not ideal: first, it's not clear which flag made one of the
      warnings an
      error. Second, warning messages are not modified in any way, so there's
      no way
      to know which warnings caused this error.
      
      With this patch we (1) promote warning messages to error messages if a
      relevant
      -Werror is enabled (2) mention which -Werror is used during this
      promotion.
      
      Previously:
      
          [1 of 1] Compiling Main             ( test.hs, test.o )
      
          test.hs:9:10: warning: [-Wincomplete-patterns]
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
            |
          9 | sInt s = case s of
            |          ^^^^^^^^^...
      
          test.hs:12:14: warning: [-Wmissing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
      1}’
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
             |
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
      
          <no location info>: error:
          Failing due to -Werror.
      
      Now:
      
          [1 of 1] Compiling Main             ( test.hs, test.o )
      
          test.hs:9:10: error: [-Wincomplete-patterns,
      -Werror=incomplete-patterns]
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
            |
          9 | sInt s = case s of
            |          ^^^^^^^^^...
      
          test.hs:12:14: error: [-Wmissing-fields, -Werror=missing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
      1}’
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
             |
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
      
      Test Plan: - Update old tests, add new tests if there aren't any
      relevant tests
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3709
      4befb415
  4. 16 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix the treatment of 'closed' definitions · dc8e6861
      Simon Peyton Jones authored
      The IdBindingInfo field of ATcId serves two purposes
      
      - to control generalisation when we have -XMonoLocalBinds
      - to check for floatability when dealing with (static e)
      
      These are related, but not the same, and they'd becomme confused.
      Trac #13804 showed this up via an example like this:
      
        f periph = let sr :: forall a. [a] -> [a]
                       sr = if periph then reverse else id
      
                       sr2 = sr
                       -- The question: is sr2 generalised?
                       -- It should be, because sr has a type sig
                       -- even though it has periph free
                   in
                   (sr2 [True], sr2 "c")
      
      Here sr2 should be generalised, despite the free var 'periph'
      in 'sr' because 'sr' has a closed type signature.
      
      I documented all this very carefully this time, in TcRnTypes:
        Note [Meaning of IdBindingInfo]
        Note [Bindings with closed types: ClosedTypeId]
      dc8e6861
  5. 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
  6. 11 Apr, 2017 1 commit
  7. 14 Mar, 2017 1 commit
  8. 23 Jan, 2017 1 commit
  9. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  10. 17 Dec, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Reshuffle levity polymorphism checks. · 8906e7b7
      eir@cis.upenn.edu authored
      Previously, GHC checked for bad levity polymorphism to the left of all
      arrows in data constructors. This was wrong, as reported in #12911
      (where an example is also shown). The solution is to check each
      individual argument for bad levity polymorphism.  Thus the check has
      been moved from TcValidity to TcTyClsDecls.
      
      A similar situation exists with pattern synonyms, also fixed here.
      
      This patch also nabs #12819 while I was in town.
      
      Test cases: typecheck/should_compile/T12911, patsyn/should_fail/T12819
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2783
      
      GHC Trac Issues: #12819, #12911
      8906e7b7
  11. 20 Jul, 2016 1 commit
    • Ömer Sinan Ağacan's avatar
      Support SCC pragmas in declaration context · 98b2c508
      Ömer Sinan Ağacan authored
      Not having SCCs at the top level is becoming annoying real quick. For
      simplest cases, it's possible to do this transformation:
      
          f x y = ...
          =>
          f = {-# SCC f #-} \x y -> ...
      
      However, it doesn't work when there's a `where` clause:
      
          f x y = <t is in scope>
            where t = ...
          =>
          f = {-# SCC f #-} \x y -> <t is out of scope>
            where t = ...
      
      Or when we have a "equation style" definition:
      
          f (C1 ...) = ...
          f (C2 ...) = ...
          f (C3 ...) = ...
          ...
      
      (usual solution is to rename `f` to `f'` and define a new `f` with a
      `SCC`)
      
      This patch implements support for SCC annotations in declaration
      contexts. This is now a valid program:
      
          f x y = ...
            where
              g z = ...
              {-# SCC g #-}
          {-# SCC f #-}
      
      Test Plan: This passes slow validate (no new failures added).
      
      Reviewers: goldfire, mpickering, austin, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: simonmar, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2407
      98b2c508
  12. 01 Jul, 2016 1 commit
  13. 25 Jun, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      s/Invisible/Inferred/g s/Visible/Required/g · 5fdb854c
      eir@cis.upenn.edu authored
      This renames VisibilityFlag from
      
      > data VisibilityFlag = Visible | Specified | Invisible
      
      to
      
      > data ArgFlag = Required | Specified | Inferred
      
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
      5fdb854c
  14. 21 Jun, 2016 1 commit
  15. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
      
        - tyConBinders :: [TyConBinder]
      
      The new data types look like this:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
      
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
      
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      
      Some smaller points
      ~~~~~~~~~~~~~~~~~~~
      * Nice new functions
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
      e368f326
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  16. 13 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of let-bindings · 15b9bf4b
      Simon Peyton Jones authored
      This major commit was initially triggered by #11339, but it spiraled
      into a major review of the way in which type signatures for bindings
      are handled, especially partial type signatures.  On the way I fixed a
      number of other bugs, namely
         #12069
         #12033
         #11700
         #11339
         #11670
      
      The main change is that I completely reorganised the way in which type
      signatures in bindings are handled. The new story is in TcSigs
      Note [Overview of type signatures].  Some specific:
      
      * Changes in the data types for signatures in TcRnTypes:
        TcIdSigInfo and new TcIdSigInst
      
      * New module TcSigs deals with typechecking type signatures
        and pragmas. It contains code mostly moved from TcBinds,
        which is already too big
      
      * HsTypes: I swapped the nesting of HsWildCardBndrs
        and HsImplicitBndsrs, so that the wildcards are on the
        oustide not the insidde in a LHsSigWcType.  This is just
        a matter of convenient, nothing deep.
      
      There are a host of other changes as knock-on effects, and
      it all took FAR longer than I anticipated :-).  But it is
      a significant improvement, I think.
      
      Lots of error messages changed slightly, some just variants but
      some modest improvements.
      
      New tests
      
      * typecheck/should_compile
          * SigTyVars: a scoped-tyvar test
          * ExPat, ExPatFail: existential pattern bindings
          * T12069
          * T11700
          * T11339
      
      * partial-sigs/should_compile
          * T12033
          * T11339a
          * T11670
      
      One thing to check:
      
      * Small change to output from ghc-api/landmines.
        Need to check with Alan Zimmerman
      15b9bf4b