1. 16 Dec, 2015 3 commits
  2. 15 Dec, 2015 7 commits
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
    • Ben Gamari's avatar
      primops: Mark actions evaluated by `catch*` as lazy · 28638dfe
      Ben Gamari authored
      There is something very peculiar about the `catch` family of operations
      with respect to strictness analysis: they turn divergence into
      non-divergence. For this reason, it isn't safe to mark them as strict in
      the expression whose exceptions they are catching. The reason is this:
      
      Consider,
      
          let r = \st -> raiseIO# blah st
          in catch (\st -> ...(r st)..) handler st
      
      If we give the first argument of catch a strict signature, we'll get a
      demand 'C(S)' for 'r'; that is, 'r' is definitely called with one
      argument, which indeed it is. The trouble comes when we feed 'C(S)' into
      'r's RHS as the demand of the body as this will lead us to conclude that
      the whole 'let' will diverge; clearly this isn't right.
      
      This is essentially the problem in #10712, which arose when
      7c0fff41 marked the `catch*` primops as
      being strict in the thing to be evaluated. Here I've partially reverted
      this commit, again marking the first argument of these primops as lazy.
      
      Fixes #10712.
      
      Test Plan: Validate checking `exceptionsrun001`
      
      Reviewers: simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1616
      
      GHC Trac Issues: #10712, #11222
      28638dfe
    • Ben Gamari's avatar
      Add testcase for #11224 · a701694b
      Ben Gamari authored
      Test Plan: Validate
      
      Reviewers: austin, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1622
      
      GHC Trac Issues: #11224
      a701694b
    • Ben Gamari's avatar
      Narrow scope of special-case for unqualified printing of names in core libraries · e2c91738
      Ben Gamari authored
      Commit 547c5971 modifies the
      pretty-printer to render names from a set of core packages (`base`,
      `ghc-prim`, `template-haskell`) as unqualified. The idea here was that
      many of these names typically are not in scope but are well-known by the
      user and therefore qualification merely introduces noise.
      
      This, however, is a very large hammer and potentially breaks any
      consumer who relies on parsing GHC output (hence #11208). This commit
      partially reverts this change, now only printing `Constraint` (which
      appears quite often in errors) as unqualified.
      
      Fixes #11208.
      
      Updates tests in `array` submodule.
      
      Test Plan: validate
      
      Reviewers: hvr, thomie, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1619
      
      GHC Trac Issues: #11208
      e2c91738
    • Simon Peyton Jones's avatar
      Allow recursive (undecidable) superclasses · 6eabb6dd
      Simon Peyton Jones authored
      This patch fulfils the request in Trac #11067, #10318, and #10592,
      by lifting the conservative restrictions on superclass constraints.
      
      These restrictions are there (and have been since Haskell was born) to
      ensure that the transitive superclasses of a class constraint is a finite
      set.  However (a) this restriction is conservative, and can be annoying
      when there really is no recursion, and (b) sometimes genuinely recursive
      superclasses are useful (see the tickets).
      
      Dimitrios and I worked out that there is actually a relatively simple way
      to do the job. It’s described in some detail in
      
         Note [The superclass story] in TcCanonical
         Note [Expanding superclasses] in TcType
      
      In brief, the idea is to expand superclasses only finitely, but to
      iterate (using a loop that already existed) if there are more
      superclasses to explore.
      
      Other small things
      
      - I improved grouping of error messages a bit in TcErrors
      
      - I re-centred the haddock.compiler test, which was at 9.8%
        above the norm, and which this patch pushed slightly over
      6eabb6dd
    • Erik de Castro Lopo's avatar
      Update expected test output for 32 bit platforms · 4c9d1eab
      Erik de Castro Lopo authored
      Test Plan: Run tests on a 32 bit platform
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1627
      4c9d1eab
    • Ben Gamari's avatar
      DynFlags Remove -fwarn-context-quantification flag · ddde542d
      Ben Gamari authored
      As mentioned in #4426 these warnings are now errors since the Great
      Wildcards Refactor of 2015 (1e041b73).
      I've opened #11221 to ensure we remove the last traces of the option in
      8.2.
      
      Test Plan: validate
      
      Reviewers: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1615
      
      GHC Trac Issues: #4426
      ddde542d
  3. 14 Dec, 2015 6 commits
  4. 12 Dec, 2015 7 commits
    • johnleo's avatar
      Refactor type families in Template Haskell · 9934819f
      johnleo authored
      Fixes #10902.
      
      Test Plan: validate
      
      Reviewers: goldfire, austin, hvr, jstolarek, bgamari
      
      Reviewed By: jstolarek, bgamari
      
      Subscribers: hvr, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1570
      
      GHC Trac Issues: #10902
      9934819f
    • Adam Sandberg Eriksson's avatar
      Make -XStrict imply -XStrictData · 4935b48b
      Adam Sandberg Eriksson authored
      Fixes #11182.
      
      Reviewers: bgamari, simonpj, austin
      
      Reviewed By: simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1592
      
      GHC Trac Issues: #11182
      4935b48b
    • Eric Seidel's avatar
      Rework the Implicit CallStack solver to handle local lets. · 3ec8288a
      Eric Seidel authored
      We can't just solve CallStack constraints indiscriminately when they
      occur in the RHS of a let-binder. The top-level given CallStack (if
      any) will not be in scope, so I've re-worked the CallStack solver as
      follows:
      
      1. CallStacks are treated like regular IPs unless one of the following
         two rules apply.
      
      2. In a function call, we push the call-site onto a NEW wanted
         CallStack, which GHC will solve as a regular IP (either directly from a
         given, or by quantifying over it in a local let).
      
      3. If, after the constraint solver is done, any wanted CallStacks
         remain, we default them to the empty CallStack. This rule exists mainly
         to clean up after rule 2 in a top-level binder with no given CallStack.
      
      In rule (2) we have to be careful to emit the new wanted with an
      IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
      again. This is a bit shady but I've updated the Note to explain the
      trick.
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1422
      
      GHC Trac Issues: #10845
      3ec8288a
    • Matthew Pickering's avatar
      Implement -fwarn-missing-pat-syn-sigs · 1883afb2
      Matthew Pickering authored
      This adds a warning when a pattern synonym is not accompanied by a
      signature in the style of `-fwarn-missing-sigs`.
      
      It is turned on by -Wall.
      
      If the user specifies, `-fwarn-missing-exported-signatures` with
      `-fwarn-missing-pat-syn-sigs` then it will only warn when the pattern
      synonym is exported.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1596
      
      GHC Trac Issues: #11053
      1883afb2
    • Edward Z. Yang's avatar
      Frontend plugins. · a3c2a26b
      Edward Z. Yang authored
      Summary:
      Frontend plugins enable users to write plugins to replace
      GHC major modes.  E.g. instead of saying
      
          ghc --make A B C
      
      a user can now say
      
          ghc --frontend GHC.Frontend.Shake A B C
      
      which might provide an alternative implementation of a multi-module
      build.  For more details, see the manual entry.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, bgamari, austin, simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1598
      
      GHC Trac Issues: #11194
      a3c2a26b
    • eir@cis.upenn.edu's avatar
      Test #9017 in polykinds/T9017 · 779dfea1
      eir@cis.upenn.edu authored
      779dfea1
    • eir@cis.upenn.edu's avatar
      Test case for #7961. · 68f198f5
      eir@cis.upenn.edu authored
      Test case: dependent/shoud_compile/TypeLevelVec
      68f198f5
  5. 11 Dec, 2015 7 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
    • Ben Gamari's avatar
      testsuite: Only run recomp015 on ELF-based platforms · ceaf0f46
      Ben Gamari authored
      It fails on OS X with hundreds of messages of the form,
      ```
      ManySections.s:196576:10: error:
           error: mach-o section specifier uses an unknown section type
      .section s65525,"",@progbits
               ^
      
      ManySections.s:196579:10: error:
           error: mach-o section specifier uses an unknown section type
      .section s65526,"",@progbits
      ```
      
      It fails on Windows with messages of the form,
      ```
      ManySections.s:196579:10: error:
           Error: junk at the end of line, first unrecognized character is ','
      ```
      
      Test Plan: Validate
      
      Reviewers: hsyl20, thomie, austin
      
      Reviewed By: thomie, austin
      
      Differential Revision: https://phabricator.haskell.org/D1601
      
      GHC Trac Issues: #11022
      ceaf0f46
    • Ben Gamari's avatar
      Removed colon append operation (fixes #10785) · c205aebd
      Ben Gamari authored
      Reviewers: jgertm, austin, thomie
      
      Reviewed By: thomie
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1164
      
      GHC Trac Issues: #10785
      c205aebd
    • Ben Gamari's avatar
      T4801: Update expected allocations on Darwin · 262954c2
      Ben Gamari authored
      262954c2
    • Ben Gamari's avatar
      Mark retc001 as broken on Darwin · 5447c20e
      Ben Gamari authored
      Due to #11204. A relatively easy fix would be to add a one second delay as
      described in the ticket, but this seems terrible.
      5447c20e
    • Ben Gamari's avatar
      T7478: Don't expect broken on Darwin · f7c17c84
      Ben Gamari authored
      This appears to be fixed as noted by goldfire on #7478 and my own
      experience.
      f7c17c84
  6. 10 Dec, 2015 2 commits
  7. 09 Dec, 2015 2 commits
    • Gabor Greif's avatar
      More typos in comments/docs · 688069ca
      Gabor Greif authored
      688069ca
    • 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
  8. 08 Dec, 2015 1 commit
  9. 07 Dec, 2015 5 commits
    • 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