1. 12 Nov, 2016 1 commit
  2. 06 Nov, 2016 1 commit
    • Tamar Christina's avatar
      Some minor linker cleanups. · 1964d869
      Tamar Christina authored
      Summary:
      Just some cleanups to some oddities I've noticed
      while investigating a linker issue.
      
      Particularly the dll name returned by `findSysDll`
      was decorated. So foo.dll is returned. We make it
      `foo.dll.dll` and later drop one `.dll` when passed to
      `addDll` which expects it without extension, but still
      tries the name *as is* which is why it worked.
      
      This should be slightly faster, since we don't try 4 loads
      before we succeed.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, erikd, simonmar, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2680
      1964d869
  3. 18 Oct, 2016 1 commit
  4. 14 Oct, 2016 1 commit
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  5. 08 Oct, 2016 4 commits
  6. 01 Oct, 2016 1 commit
    • mniip's avatar
      GHCi: Don't remove shadowed bindings from typechecker scope. · 59d7ee53
      mniip authored
      The shadowed out bindings are accessible via qualified names like
      Ghci1.foo.  Since they are accessable in the renamer the typechecker
      should be able to see them too.  As a consequence they show up in :show
      bindings.
      
      This fixes T11547
      
      Test Plan:
      Fixed current tests to accomodate to new stuff in :show bindings
      Added a test that verifies that the typechecker doesn't crash
      
      Reviewers: austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2447
      
      GHC Trac Issues: #11547
      59d7ee53
  7. 26 Aug, 2016 1 commit
  8. 21 Aug, 2016 1 commit
    • Edward Z. Yang's avatar
      Axe initIfaceTc, tie the knot through HPT (or if_rec_types). · e907e1f1
      Edward Z. Yang authored
      Summary:
      initIfaceTc was originally used to make sure when we typecheck
      an interface, it can find the TyThings for things it itself
      defined.  However, in the case of retypecheckLoop, this wasn't
      necessary because we ALREADY tied the knot through the HPT.
      
      This commit removes initIfaceTc, instead relying on the HPT
      to tie the knot.  genModDetails' caller needed to be modified
      to tie the knot, but there are not that many call-sites of
      typecheckIface so the change is quite reasonable.
      
      We also introduce a new 'initIfaceLoad', which does
      NOT set up 'if_rec_types'.  It's used when we're
      typechecking old, up-to-date interfaces in, since we're
      never going to update the type environment.
      
      The full details are in Note [Knot-tying typecheckIface].
      Displeasingly, we need a special case to handle DFuns in
      the case of tcHiBootIface, see
      Note [DFun knot-tying special case] for the gory details.
      
      I also added another test which tickles a bug in a buggy
      version of this patch (see "Why the seq?")
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2349
      e907e1f1
  9. 08 Aug, 2016 1 commit
  10. 05 Jul, 2016 3 commits
  11. 22 Jun, 2016 1 commit
  12. 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
  13. 07 Jun, 2016 1 commit
    • niteria's avatar
      Make vectInfoParallelVars a DVarSet · 5db93d2e
      niteria authored
      We dump it in the interface file, so we need to do it in a
      deterministic order. I haven't seen any problems with this
      during my testing, but that's probably because it's unused.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2313
      
      GHC Trac Issues: #4012
      5db93d2e
  14. 06 Jun, 2016 1 commit
    • niteria's avatar
      Use UniqDFM for HomePackageTable · 3042a9d8
      niteria authored
      This isn't strictly necessary for deterministic ABIs.
      The results of eltsHpt are consumed in two ways:
      1) they determine the order of linking
      2) if you track the data flow all the family instances get put in
         FamInstEnvs, so the nondeterministic order is forgotten.
      3) same for VectInfo stuff
      4) same for Annotations
      
      The problem is that I haven't found a nice way to do 2. in
      a local way and 1. is nice to have if we went for deterministic
      object files. Besides these maps are keyed on ModuleNames so they
      should be small relative to other things and the overhead should
      be negligible.
      
      As a bonus we also get more specific names.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, hvr, ezyang, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2300
      
      GHC Trac Issues: #4012
      3042a9d8
  15. 24 May, 2016 1 commit
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Summary:
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: austin, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2260
      95dfdceb
  16. 12 May, 2016 1 commit
  17. 01 May, 2016 1 commit
  18. 25 Jan, 2016 1 commit
  19. 24 Jan, 2016 1 commit
  20. 20 Jan, 2016 1 commit
  21. 18 Jan, 2016 3 commits
    • Edward Z. Yang's avatar
      Switch from -this-package-key to -this-unit-id. · 240ddd7c
      Edward Z. Yang authored
      A small cosmetic change, but we have to do a bit of work to
      actually support it:
      
          - Cabal submodule update, so that Cabal passes us
            -this-unit-id when we ask for it.  This includes
            a Cabal renaming to be consistent with Unit ID, which
            makes ghc-pkg a bit more scrutable.
      
          - Build system is updated to use -this-unit-id rather than
            -this-package-key, to avoid deprecation warnings.  Needs
            a version test so I resurrected the old test we had
            (sorry rwbarton!)
      
          - I've *undeprecated* -package-name, so that we are in the same
            state as GHC 7.10, since the "correct" flag will have only
            entered circulation in GHC 8.0.
      
          - I removed -package-key.  Since we didn't deprecate -package-id
            I think this should not cause any problems for users; they
            can just change their code to use -package-id.
      
          - The package database is indexed by UNIT IDs, not component IDs.
            I updated the naming here.
      
          - I dropped the signatures field from ExposedModule; nothing
            was using it, and instantiatedWith from the package database
            field.
      
          - ghc-pkg was updated to use unit ID nomenclature, I removed
            the -package-key flags but I decided not to add any new flags
            for now.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: 23Skidoo, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1780
      240ddd7c
    • 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
    • Eric Seidel's avatar
      un-wire-in error, undefined, CallStack, and IP · a7b751db
      Eric Seidel authored
      I missed a crucial step in the wiring-in process of `CallStack` in D861,
      the bit where you actually wire-in the Name... This led to a nasty bug
      where GHC thought `CallStack` was not wired-in and tried to fingerprint
      it, which failed because the defining module was not loaded.
      
      But we don't need `CallStack` to be wired-in anymore since `error` and
      `undefined` no longer need to be wired-in. So we just remove them all.
      
      Updates haddock submodule.
      
      Test Plan: `./validate` and `make slowtest TEST=tc198`
      
      Reviewers: simonpj, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: goldfire, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1739
      
      GHC Trac Issues: #11331
      a7b751db
  22. 15 Jan, 2016 1 commit
  23. 08 Jan, 2016 1 commit
    • Simon Marlow's avatar
      Enable stack traces with ghci -fexternal-interpreter -prof · 6be09e88
      Simon Marlow authored
      Summary:
      The main goal here is enable stack traces in GHCi.  After this change,
      if you start GHCi like this:
      
        ghci -fexternal-interpreter -prof
      
      (which requires packages to be built for profiling, but not GHC
      itself) then the interpreter manages cost-centre stacks during
      execution and can produce a stack trace on request.  Call locations
      are available for all interpreted code, and any compiled code that was
      built with the `-fprof-auto` familiy of flags.
      
      There are a couple of ways to get a stack trace:
      
      * `error`/`undefined` automatically get one attached
      * `Debug.Trace.traceStack` can be used anywhere, and prints the current
        stack
      
      Because the interpreter is running in a separate process, only the
      interpreted code is running in profiled mode and the compiler itself
      isn't slowed down by profiling.
      
      The GHCi debugger still doesn't work with -fexternal-interpreter,
      although this patch gets it a step closer.  Most of the functionality
      of breakpoints is implemented, but the runtime value introspection is
      still not supported.
      
      Along the way I also did some refactoring and added type arguments to
      the various remote pointer types in `GHCi.RemotePtr`, so there's
      better type safety and documentation in the bridge code between GHC
      and ghc-iserv.
      
      Test Plan: validate
      
      Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1747
      
      GHC Trac Issues: #11047, #11100
      6be09e88
  24. 31 Dec, 2015 1 commit
  25. 21 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Maintain cost-centre stacks in the interpreter · c8c44fd9
      Simon Marlow authored
      Summary:
      Breakpoints become SCCs, so we have detailed call-stack info for
      interpreted code.  Currently this only works when GHC is compiled with
      -prof, but D1562 (Remote GHCi) removes this constraint so that in the
      future call stacks will be available without building your own GHCi.
      
      How can you get a stack trace?
      
      * programmatically: GHC.Stack.currentCallStack
      * I've added an experimental :where command that shows the stack when
        stopped at a breakpoint
      * `error` attaches a call stack automatically, although since calls to
        `error` are often lifted out to the top level, this is less useful
        than it might be (ImplicitParams still works though).
      * Later we might attach call stacks to all exceptions
      
      Other related changes in this diff:
      
      * I reduced the number of places that get ticks attached for
        breakpoints.  In particular there was a breakpoint around the whole
        declaration, which was often redundant because it bound no variables.
        This reduces clutter in the stack traces and speeds up compilation.
      
      * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few
        other small cleanups
      
      Test Plan: validate
      
      Reviewers: ezyang, bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1595
      
      GHC Trac Issues: #11047
      c8c44fd9
  26. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  27. 15 Dec, 2015 1 commit
    • 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
  28. 11 Dec, 2015 2 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
  29. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
      
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
      
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
      
        HsExplicitFlag disappears altogether.
      
      * Other simplifications
      
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
      
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
      
           - PatSynSig records a LHsSigType rather than the decomposed
             pieces
      
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      
      * Renamed LHsTyVarBndrs to LHsQTyVars
      
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      
      I also did a bunch of loosely-related changes:
      
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
      
            TcCoercionN/TcCoercionR
      
            mkWpCastN/mkWpCastN
      
        All just type synonyms but jolly useful.
      
      * I record-ised ForeignImport and ForeignExport
      
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      
      Updates haddock submodule.
      1e041b73
  30. 25 Nov, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor default methods (Trac #11105) · 924f8517
      Simon Peyton Jones authored
      This patch does some signficant refactoring to the treatment
      of default methods in class declarations, and more generally
      to the type checking of type/class decls.
      
      Highlights:
      
      * When the class has a generic-default method, such as
           class C a where
             op :: a -> a -> Bool
             default op :: Ord a => a -> a -> a
        the ClassOpItem records the type of the generic-default,
        in this case the type (Ord a => a -> a -> a)
      
      * I killed off Class.DefMeth in favour of the very-similar
        BasicTypes.DefMethSpec.  However it turned out to be better
        to use a Maybe, thus
            Maybe (DefMethSpec Type)
        with Nothing meaning "no default method".
      
      * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing],
        but I found a way to make it much simpler, accumulating only
        a [TyCon].  Much less wrapping and unwrapping.
      
      * On the way I also fixed Trac #10896 in a better way. Instead
        of killing off all ambiguity checks whenever there are any type
        errors (the fix in commit 8e8b9ed9), I instead recover in
        TcTyClsDecls.checkValidTyCl.
      
      There was a lot of associated simplification all round
      924f8517
  31. 18 Nov, 2015 1 commit