1. 06 Sep, 2014 1 commit
  2. 05 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      
      
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D80
      66218d15
  3. 02 Jul, 2014 2 commits
  4. 17 Feb, 2014 1 commit
  5. 20 Jan, 2014 1 commit
    • Gergő Érdi's avatar
      Implement pattern synonyms · 4f8369bf
      Gergő Érdi authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      
      The rundown is this:
      
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
      
        * Unidirectional patterns are declared like thus:
      
              pattern P x <- x:_
      
          The synonym 'P' may only occur in a pattern context:
      
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
      
        * Bidirectional patterns are declared like thus:
      
              pattern P x y = [x, y]
      
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
      
              bar :: Int -> [Int]
              bar x = P x 10
      
        * Patterns can't yet have their own type signatures; signatures are inferred.
      
        * Pattern synonyms may not be recursive, c.f. type synonyms.
      
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
      
              module Foo (pattern Bar) where ...
      
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
      
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
      
              pattern P x y <- [x, y]
      
              f (P True True) = True
              f _             = False
      
              g [True, True] = True
              g _            = False
      
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      
      For more information, see the wiki:
      
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation
      
      Reviewed-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      4f8369bf
  6. 27 Nov, 2013 1 commit
  7. 13 Nov, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Make type-level evaluation work with :kind! · b2fa2d41
      Iavor S. Diatchki authored
      The main change is to add a case to `reduceTyFamApp_maybe` to evaluate
      built-in type constructors (e.g., (+), (*), and friends).
      
      To avoid problems with recursive modules, I moved the definition of
      TcBuiltInSynFamily from `FamInst` to `FamInstEnv`.  I am still not sure if
      this is the right place.
      
      There is also a wibble that it'd be nice to fix:
      
      when we evaluate a built-in type function, using`sfMatchFam`, we get
      a `TcCoercion`.  However, `reduceTyFamApp_maybe` needs a `Corecion`.
      I couldn't find a nice way to convert between the two, so I resorted to
      a bit of hack (marked with `XXX`).
      
      The hack is that we happen to know that the built-in constructors for
      the type-nat functions always return coercions of shape `TcAxiomRuleCo`,
      with no assumptions, so it easy to convert `TcCoercion` to `Coercion`
      in this one case.  This is enough to make things work, but it is clearly
      a cludge.
      b2fa2d41
  8. 11 Oct, 2013 1 commit
  9. 01 Oct, 2013 1 commit
  10. 23 Sep, 2013 1 commit
    • gmainlan@microsoft.com's avatar
      SIMD primops are now generated using schemas that are polymorphic in · 16b350a4
      gmainlan@microsoft.com authored
      width and element type.
      
      SIMD primops are now polymorphic in vector size and element type, but
      only internally to the compiler. More specifically, utils/genprimopcode
      has been extended so that it "knows" about SIMD vectors. This allows us
      to, for example, write a single definition for the "add two vectors"
      primop in primops.txt.pp and have it instantiated at many vector types.
      This generates a primop in GHC.Prim for each vector type at which "add
      two vectors" is instantiated, but only one data constructor for the
      PrimOp data type, so the code generator is much, much simpler.
      16b350a4
  11. 22 Sep, 2013 1 commit
  12. 18 Sep, 2013 3 commits
    • Jan Stolarek's avatar
      Restore old names of comparison primops · 53948f91
      Jan Stolarek authored
      In 6579a6c7 we removed existing comparison primops and introduced new ones
      returning Int# instead of Bool. This commit (and associated commits in
      array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and
      template-haskell) restores old names of primops. This allows us to keep
      our API cleaner at the price of not having backwards compatibility.
      
      This patch also temporalily disables fix for #8317 (optimization of
      tagToEnum# at Core level). We need to fix #8326 first, otherwise
      our primops code will be very slow.
      53948f91
    • Jan Stolarek's avatar
      Trailing whitespaces · 6eec7bc5
      Jan Stolarek authored
      6eec7bc5
    • twanvl's avatar
      Implement checkable "minimal complete definitions" (#7633) · bd42c9df
      twanvl authored
      
      
      This commit adds a `{-# MINIMAL #-}` pragma, which defines the possible
      minimal complete definitions for a class. The body of the pragma is a
      boolean formula of names.
      
      The old warning for missing methods is replaced with this new one.
      
      Note: The interface file format is changed to store the minimal complete
      definition.
      Authored-by: twanvl's avatarTwan van Laarhoven <twanvl@gmail.com>
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      bd42c9df
  13. 13 Sep, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Add support for evaluation of type-level natural numbers. · 1f77a534
      Iavor S. Diatchki authored
      This patch implements some simple evaluation of type-level expressions
      featuring natural numbers.  We can evaluate *concrete* expressions that
      use the built-in type families (+), (*), (^), and (<=?), declared in
      GHC.TypeLits.   We can also do some type inference involving these
      functions.  For example, if we encounter a constraint such as `(2 + x) ~ 5`
      we can infer that `x` must be 3.  Note, however, this is used only to
      resolve unification variables (i.e., as a form of a constraint improvement)
      and not to generate new facts.  This is similar to how functional
      dependencies work in GHC.
      
      The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
      of a new form of axiom called `CoAxiomRule`.  This is the form of evidence
      generate when we solve a constraint, such as `(1 + 2) ~ 3`.
      
      The patch also adds support for built-in type-families, by adding a new
      form of TyCon rhs: `BuiltInSynFamTyCon`.  such built-in type-family
      constructors contain a record with functions that are used by the
      constraint solver to simplify and improve constraints involving the
      built-in function (see `TcInteract`).  The record in defined in `FamInst`.
      
      The type constructors and rules for evaluating the type-level functions
      are in a new module called `TcTypeNats`.
      1f77a534
  14. 09 Sep, 2013 1 commit
    • thoughtpolice's avatar
      Fix optimization of Parser.y.pp · 9f8e9d29
      thoughtpolice authored
      
      
      In 9e133b, the build was modified to pass -fcmm-sink to Parser, but
      unfortunately Parser specifies -O0 in its OPTIONS_GHC directive, meaning
      the sinking pass was actually turned off.
      
      HC_OPTS is the last thing passed to the compiler for that source file
      however, so the correct fix is to also move -O0 out into the build
      system as well.
      
      This was uncovered thanks to a build report from Kazu Yamamoto. Thanks
      to Jan Stolarek for eyeballing this bug and finding it.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      9f8e9d29
  15. 04 Sep, 2013 1 commit
    • thoughtpolice's avatar
      Make sure -fcmm-sink is passed to Parser properly · 9e133b9d
      thoughtpolice authored
      
      
      Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
      register allocator doesn't run out of stack slots. Previously, we had to
      do some CPP hacks in order to emit an #ifdef into the file - this is
      because we preprocess it once up front, and run the preprocessor again
      when we compile it.
      
      There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
      needs the flag, or the stage1 compiler is compiling the stage2
      Parser.hs, and needs the flag..
      
      The previous approach was super fragile with Clang. The more principled
      fix is to instead do this through the build system.
      
      This fixes #8182.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      9e133b9d
  16. 27 Aug, 2013 1 commit
    • parcs's avatar
      UniqSupply: make mkSplitUniqSupply thread-safe · 036910ad
      parcs authored
      unsafeInterleaveIO is used instead of unsafeDupableInterleaveIO because
      a mk_supply thunk that is simultaneously entered by two threads should
      evaluate to the same UniqSupply.
      
      The UniqSupply counter is now incremented atomically using the RTS's
      atomic_inc().
      
      To mitigate the extra overhead of unsafeInterleaveIO in the
      single-threaded compiler, noDuplicate# is changed to exit early when
      n_capabilities == 1.
      036910ad
  17. 02 Aug, 2013 1 commit
  18. 15 May, 2013 1 commit
  19. 07 Apr, 2013 1 commit
  20. 06 Apr, 2013 2 commits
  21. 15 Mar, 2013 1 commit
  22. 11 Mar, 2013 1 commit
  23. 03 Mar, 2013 3 commits
  24. 02 Mar, 2013 1 commit
  25. 01 Mar, 2013 1 commit
  26. 19 Feb, 2013 1 commit
  27. 18 Feb, 2013 1 commit
  28. 17 Feb, 2013 1 commit
  29. 15 Feb, 2013 1 commit
  30. 17 Jan, 2013 1 commit
    • Simon Marlow's avatar
      Tidy up cross-compiling · 109a1e53
      Simon Marlow authored
      We have two cases:
       1. building a cross-compiler
       2. compiling GHC to run on a foreign platform
      
      These two are done with almost the same setup: (1) is the stage 1
      compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
      
      The only difference between (1) and (2) is that you if you set up the
      build for (1), then it stops before stage 2 and you can 'make install'
      to install stage 1.
      
      Unfortunately, (2) didn't work, and the build system code needed some
      tidying up.
      
      Change to the way the build is set up:
      
      Before
      ------
      
      To build a cross-compiler:
        ./configure --target=<..>
      
      To compile a foreign GHC:
        ./configure --host=<..> --target=<..>
      
      Now
      ---
      
      To build a cross-compiler:
        ./configure --target=<..>
        And set "Stage1Only=YES" in mk/build.mk
      
      To compile a foreign GHC:
        ./configure --target=<..>
      109a1e53
  31. 05 Dec, 2012 1 commit
    • ian@well-typed.com's avatar
      Don't define DYNAMIC when compiling the dyn way · 3fc453af
      ian@well-typed.com authored
      We want to compile the sources only once, and to produce both vanilla
      and dyn object files. This means that the sources can't differ for the
      two ways.
      
      This needed a bit of a kludge to get keepCAFsForGHCi included only in
      the dynamic library.
      3fc453af
  32. 30 Nov, 2012 1 commit
  33. 23 Nov, 2012 1 commit
  34. 12 Nov, 2012 1 commit
    • ian@well-typed.com's avatar
      Replace mkDerivedConstants.c with DeriveConstants.hs · f49271c0
      ian@well-typed.com authored
      DeriveConstants.hs works in a cross-compilation-friendly way. Rather
      than running a C program that prints out the constants, we just compile
      a C file which has the constants are encoded in symbol sizes. We then
      parse the output of 'nm' to find out what the constants are.
      
      Based on work by Gabor Greif <ggreif@gmail.com>.
      f49271c0