1. 17 Dec, 2016 1 commit
    • Rufflewind's avatar
      Windows: Improve terminal detection mechanism · 3dbd2b09
      Rufflewind authored
      The previous detection mechanism allowed environment variables (ANSICON,
      ConEmuANSI, TERM) to supersede the fact that the stderr is not a
      terminal, which is probably what led to color codes appearing in the
      stderr of the tests (see: 847d2293).
      
      This commit changes the detection mechanism to detect Cygwin/MSYS2
      terminals in a more reliable manner, avoiding the use of environment
      variables entirely.
      
      Test Plan: validate
      
      Reviewers: Phyx, austin, erikd, bgamari
      
      Reviewed By: Phyx, bgamari
      
      Subscribers: RyanGlScott, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2809
      3dbd2b09
  2. 15 Dec, 2016 1 commit
  3. 29 Nov, 2016 2 commits
  4. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored
      Here we consolidate the pretty-printing logic for types in IfaceType. We
      need IfaceType regardless and the printer for Type can be implemented in
      terms of that for IfaceType. See #11660.
      
      Note that this is very much a work-in-progress. Namely I still have yet
      to ponder how to ease the hs-boot file situation, still need to rip out
      more dead code, need to move some of the special cases for, e.g., `*` to
      the IfaceType printer, and need to get it to validate. That being said,
      it comes close to validating as-is.
      
      Test Plan: Validate
      
      Reviewers: goldfire, austin
      
      Subscribers: goldfire, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2528
      
      GHC Trac Issues: #11660
      6c0f10fa
  5. 12 Nov, 2016 1 commit
  6. 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
  7. 08 Oct, 2016 3 commits
  8. 06 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Refactor TcDeriv and TcGenDeriv · 4a03012a
      Ryan Scott authored
      Summary:
      Keeping a promise I made to Simon to clean up these modules.
      
      This change splits up the massive `TcDeriv` and `TcGenDeriv` modules into
      somewhat more manageable pieces. The new modules are:
      
      * `TcGenFunctor`: This contains the deriving machinery for `Functor`,
        `Foldable`, and `Traversable` (which all use the same underlying algorithm).
      * `TcDerivInfer`: This is the new home for `inferConstraints`,
        `simplifyInstanceContexts`, and related functions, whose role is to come up
        with the derived instance context and subsequently simplify it.
      * `TcDerivUtils`: This is a grab-bag module that contains several
        error-checking utilities originally in `TcDeriv`, as well as some functions
        that `TcDeriv` and `TcDerivInfer` both need.
      
      The end result is that `TcDeriv` is now less than 1,600 SLOC (originally 2,686
      SLOC), and `TcGenDeriv` is now about 2,000 SLOC (originally 2,964).
      
      In addition, this also implements a couple of tiny refactorings:
      
      * I transformed `type Condition = (DynFlags, TyCon) -> Validity` into
        `type Condition = DynFlags -> TyCon -> Validity`
      * I killed the `DerivSpecGeneric` constructor for `DerivSpecMechanism`, and
        merged its functionality into `DerivSpecStock`. In addition,
        `hasStockDeriving` now contains key-value pairs for `Generic` and `Generic1`,
        so they're no longer treated as an awkward special case in `TcDeriv`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2568
      4a03012a
  9. 22 Jul, 2016 1 commit
    • Simon Marlow's avatar
      Add deepseq dependency and a few NFData instances · c4f3d91b
      Simon Marlow authored
      I needed to rnf a data structure (CompiledByteCode) but we don't have
      any good deepseq infrastructure in the compiler yet.  There are bits and
      pieces, but nothing consistent, so this is a start.
      
      We already had a dependency on deepseq indirectly via other packages
      (e.g. containers).
      
      Includes an update to the haddock submodule, to remove orphan NFData
      instances in there.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, erikd, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2418
      c4f3d91b
  10. 21 Jul, 2016 1 commit
    • Ömer Sinan Ağacan's avatar
      Implement unboxed sum primitive type · 714bebff
      Ömer Sinan Ağacan authored
      Summary:
      This patch implements primitive unboxed sum types, as described in
      https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.
      
      Main changes are:
      
      - Add new syntax for unboxed sums types, terms and patterns. Hidden
        behind `-XUnboxedSums`.
      
      - Add unlifted unboxed sum type constructors and data constructors,
        extend type and pattern checkers and desugarer.
      
      - Add new RuntimeRep for unboxed sums.
      
      - Extend unarise pass to translate unboxed sums to unboxed tuples right
        before code generation.
      
      - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
        code generation when sum values are involved.
      
      - Add user manual section for unboxed sums.
      
      Some other changes:
      
      - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
        `MultiValAlt` to be able to use those with both sums and tuples.
      
      - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
        wrong, given an `Any` `TyCon`, there's no way to tell what its kind
        is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.
      
      - Fix some bugs on the way: #12375.
      
      Not included in this patch:
      
      - Update Haddock for new the new unboxed sum syntax.
      
      - `TemplateHaskell` support is left as future work.
      
      For reviewers:
      
      - Front-end code is mostly trivial and adapted from unboxed tuple code
        for type checking, pattern checking, renaming, desugaring etc.
      
      - Main translation routines are in `RepType` and `UnariseStg`.
        Documentation in `UnariseStg` should be enough for understanding
        what's going on.
      
      Credits:
      
      - Johan Tibell wrote the initial front-end and interface file
        extensions.
      
      - Simon Peyton Jones reviewed this patch many times, wrote some code,
        and helped with debugging.
      
      Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
                 simonmar, hvr, erikd
      
      Reviewed By: simonpj
      
      Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
                   thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2259
      714bebff
  11. 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
  12. 23 May, 2016 1 commit
    • Ben Gamari's avatar
      Revert "compiler/iface: compress .hi files" · 9bb27726
      Ben Gamari authored
      This appears to cause validation issues on,
      
          TEST="T11108 T9071 T11076 T7600 T7672 T8329 T10420 T10322 T8308 T4114a
          T4114c T10602 T10110 T9204 T2435 T9838 T4114d T10233 T8696 T1735 T5281
          T6056 T10134 T9580 T6018 T9762 T8103"
      
      With compiler panics of the form,
      
          Compile failed (status 256) errors were:
          ghc: panic! (the 'impossible' happened)
            (GHC version 8.1.20160523 for x86_64-unknown-linux):
                  Binary.readBinMem: decompression failed
          CallStack (from HasCallStack):
            error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary
      
          Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
      
      This reverts commit d9cb7a8a.
      9bb27726
  13. 21 May, 2016 1 commit
    • Austin Seipp's avatar
      compiler/iface: compress .hi files · d9cb7a8a
      Austin Seipp authored
      Compress all interface files generated by the compiler with LZ4. While
      being only a tiny amount of code, LZ4 is both fast at compression and
      decompression, and has good compression ratios.
      
      Non-scientific size test: size of stage2 compiler .hi files:
      
      `find ./compiler/stage2 -type f -iname '*.hi' -exec du -ch {} + | grep total$`
      
      Without this patch: 22MB of .hi files for stage2.
      With this patch: 9.2MB of .hi files for stage2.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1159
      d9cb7a8a
  14. 18 May, 2016 1 commit
    • Dave Laing's avatar
      Rework parser to allow use with DynFlags · 39a2faa0
      Dave Laing authored
      Split out the options needed by the parser from DynFlags, making the
      parser more friendly to standalone usage.
      
      Test Plan: validate
      
      Reviewers: simonmar, alanz, bgamari, austin, thomie
      
      Reviewed By: simonmar, alanz, bgamari, thomie
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2208
      
      GHC Trac Issues: #10961
      39a2faa0
  15. 19 Jan, 2016 1 commit
  16. 18 Jan, 2016 1 commit
    • 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
  17. 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
  18. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  19. 20 Dec, 2015 1 commit
  20. 18 Dec, 2015 1 commit
  21. 17 Dec, 2015 2 commits
    • Simon Marlow's avatar
      Fix libffi dependency, and remove redundant LibFFI.hsc · 27f47cda
      Simon Marlow authored
      LibFFI.hsc was moved to libraries/ghci/GHCi/FFI.hsc, I just forgot to
      remove the old one.  We also need an explicit dependency on libffi,
      which moves from compiler/ghc.mk to the top-level ghc.mk (because
      libraries/ghci/ghc.mk is auto-generated).
      27f47cda
    • 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
  22. 16 Dec, 2015 1 commit
  23. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  24. 03 Dec, 2015 1 commit
    • Georgios Karachalias's avatar
      Major Overhaul of Pattern Match Checking (Fixes #595) · 8a506104
      Georgios Karachalias authored
      This patch adresses several problems concerned with exhaustiveness and
      redundancy checking of pattern matching. The list of improvements includes:
      
      * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.).
        This fixes #4139, #3927, #8970 and other related tickets.
      
      * Making the check laziness-aware. Cases that are overlapped but affect
        evaluation are issued now with "Patterns have inaccessible right hand side".
        Additionally, "Patterns are overlapped" is now replaced by "Patterns are
        redundant".
      
      * Improved messages for literals. This addresses tickets #5724, #2204, etc.
      
      * Improved reasoning concerning cases where simple and overloaded
        patterns are matched (See #322).
      
      * Substantially improved reasoning for pattern guards. Addresses #3078.
      
      * OverloadedLists extension does not break exhaustiveness checking anymore
        (addresses #9951). Note that in general this cannot be handled but if we know
        that an argument has type '[a]', we treat it as a list since, the instance of
        'IsList' gives the identity for both 'fromList' and 'toList'. If the type is
        not clear or is not the list type, then the check cannot do much still. I am
        a bit concerned about OverlappingInstances though, since one may override the
        '[a]' instance with e.g. an '[Int]' instance that is not the identity.
      
      * Improved reasoning for nested pattern matching (partial solution). Now we
        propagate type and (some) term constraints deeper when checking, so we can
        detect more inconsistencies. For example, this is needed for #4139.
      
      I am still not satisfied with several things but I would like to address at
      least the following before the next release:
          Term constraints are too many and not printed for non-exhaustive matches
      (with the exception of literals). This sometimes results in two identical (in
      appearance) uncovered warnings. Unless we actually show their difference, I
      would like to have a single warning.
      8a506104
  25. 21 Nov, 2015 2 commits
    • niteria's avatar
      Create a deterministic version of tyVarsOfType · 2325bd4e
      niteria authored
      I've run into situations where I need deterministic `tyVarsOfType` and
      this implementation achieves that and also brings an algorithmic
      improvement.  Union of two `VarSet`s takes linear time the size of the
      sets and in the worst case we can have `n` unions of sets of sizes
      `(n-1, 1), (n-2, 1)...` making it quadratic.
      
      One reason why we need deterministic `tyVarsOfType` is in `abstractVars`
      in `SetLevels`. When we abstract type variables when floating we want
      them to be abstracted in deterministic order.
      
      Test Plan: harbormaster
      
      Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1468
      
      GHC Trac Issues: #4012
      2325bd4e
    • niteria's avatar
      Add DVarSet - a deterministic set of Vars · 6664ab83
      niteria authored
      This implements `DVarSet`, a deterministic set of Vars, with an
      interface very similar to `VarSet` with a couple of functions missing.
      
      I will need this in changes that follow, one of them will be about
      changing the type of the set of Vars that `RuleInfo` holds to make the
      free variable computation deterministic.
      
      Test Plan:
      ./validate
      I can add new tests if anyone wants me to.
      
      Reviewers: simonpj, simonmar, austin, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1487
      
      GHC Trac Issues: #4012
      6664ab83
  26. 11 Nov, 2015 1 commit
    • Sylvain HENRY's avatar
      Systools: read ELF section without calling readelf · 109d7ce8
      Sylvain HENRY authored
      This patch tackles two issues:
      
      1) GHC stores a "link info" string into a ELF section. Initially a
      section with type "note" was used but GHC didn't follow the ELF
      specification which specifies a record-based format for these sections.
      With D1375 we switched to a "progbits" section type for which there
      isn't any format constraint. This is an issue for D1242 which use GCC's
      --gc-sections which collects "unused" sections, such as our section
      containing link info... In this patch, we fall back to a section with
      type "note" but we respect the specified format.
      
      2) Reading back the ELF section was done by parsing the result of a
      call to "readelf". Calling readelf is problematic because the program
      may not be available or it may be renamed on some platforms (see
      D1326). Moreover we have no garanty that its output layout will stay
      the same in future releases of readelf. Finally we would need to fix
      the parsing to support  "note" sections because of 1. Instead, this
      patch proposes to use Data.Binary.Get to directly read the "link info"
      note into its section. ELF has a specification, hence it should work on
      every conforming platform.
      
      This patch "reverts" D1375, hence it supersedes D1432. It makes D1326
      not necessary anymore.
      
      Test Plan:
      - recomp011 should pass (test that relinking is avoided when both "link
      info" match)
      - we should add a test for ELF objects with more than 0xff00 sections
      => added test "recomp015"
      - we should check that GAS generates 32-bit words with .int on every
      supported platform using ELF (or find a place where this is
      documented). harbomaster and I (@hsyl20) only tested on x86-64. On
      platforms where it is not true, it should make recomp011 fail. =>
      tested to work on Linux/amd64, Solaris/i386 and OpenBSD/amd64
      
      Reviewers: olsner, ony, thomie, kgardas, austin, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: kgardas, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1381
      
      GHC Trac Issues: #10974, #11022
      109d7ce8
  27. 02 Nov, 2015 1 commit
  28. 01 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Update process submodule · de8443c1
      Herbert Valerio Riedel authored
      This is needed to prepare for #11026 as this update
      relaxes the upper bounds on `base` to allow for `base-4.9.0.0`
      
      This also needs to relax a few upper bounds on process in some cabal files
      
      (there will be another process submodule update soon, as a major
      version bump of process' version is still pending)
      de8443c1
  29. 30 Oct, 2015 2 commits
    • niteria's avatar
      Make type-class dictionary let binds deterministic · a5cb27f3
      niteria authored
      When generating dictionary let binds in dsTcEvBinds we may
      end up generating them in arbitrary order according to Unique order.
      
      Consider:
      
      ```
      let $dEq = GHC.Classes.$fEqInt in
      let $$dNum = GHC.Num.$fNumInt in ...
      ```
      
      vs
      
      ```
      let $dNum = GHC.Num.$fNumInt in
      let $dEq = GHC.Classes.$fEqInt in ...
      ```
      
      The way this change fixes it is by using `UniqDFM` - a type of
      deterministic finite maps of things keyed on `Unique`s. This way when
      you pull out evidence variables corresponding to type-class dictionaries
      they are in deterministic order.
      
      Currently it's the order of insertion and the way it's implemented is by
      tagging the values with the time of insertion.
      
      Test Plan:
      I've added a new test case to reproduce the issue.
      ./validate
      
      Reviewers: ezyang, simonmar, austin, simonpj, bgamari
      
      Reviewed By: simonmar, simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1396
      
      GHC Trac Issues: #4012
      a5cb27f3
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  30. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  31. 16 Oct, 2015 1 commit
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      This implements DuplicateRecordFields, the first part of the
      OverloadedRecordFields extension, as described at
      https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
      
      This includes fairly wide-ranging changes in order to allow multiple
      records within the same module to use the same field names.  Note that
      it does *not* allow record selector functions to be used if they are
      ambiguous, and it does not have any form of type-based disambiguation
      for selectors (but it does for updates). Subsequent parts will make
      overloading selectors possible using orthogonal extensions, as
      described on the wiki pages.  This part touches quite a lot of the
      codebase, and requires changes to several GHC API datatypes in order
      to distinguish between field labels (which may be overloaded) and
      selector function names (which are always unique).
      
      The Haddock submodule has been adapted to compile with the GHC API
      changes, but it will need further work to properly support modules
      that use the DuplicateRecordFields extension.
      
      Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
      will be extended once the other parts are implemented.
      
      Reviewers: goldfire, bgamari, simonpj, austin
      
      Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
      goldfire
      
      Differential Revision: https://phabricator.haskell.org/D761
      b1884b0e
  32. 15 Oct, 2015 1 commit
  33. 13 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Make dataToQa aware of Data instances which use functions to implement toConstr · d2f9972a
      Ryan Scott authored
      Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
      freak out if using a `Data` instance that produces a `Constr` (by means of
      `toConstr`) using a function name instead of a data constructor name. While
      such `Data` instances are somewhat questionable, they are nevertheless present
      in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
      aware of their existence.
      
      In order to properly distinguish strings which represent variables (as opposed
      to data constructors), it was necessary to move functionality from `Lexeme` (in
      `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
      `bin-package-db`).
      
      Reviewed By: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1313
      
      GHC Trac Issues: #10796
      d2f9972a