1. 06 Aug, 2015 9 commits
    • eir@cis.upenn.edu's avatar
      Rejigger OSMem.my_mmap to allow building on Mac · bc43d23a
      eir@cis.upenn.edu authored
      Previously, the prot and flags variables were set but never used
      on Mac (darwin). This caused a warning, and the build setup stopped
      compilation. This commit is intended simply to omit these variables
      when building with darwin_HOST_OS set. No change in behavior on any
      platform is intended.
    • rwbarton's avatar
    • Ben Gamari's avatar
      llvmGen: Rework LLVM mangler · 600b153a
      Ben Gamari authored
      The LLVM mangler does not currently transform AVX instructions on x86-64
      platforms, due to a missing #include. Also, it is significantly more
      complicated than necessary, due to the file into sections (not needed
      anymore), and is sensitive to the details of the whitespace in the
      Author: dobenour
      Test Plan: Validation on x86-64, x86-32, and ARM
      Reviewers: austin
      Subscribers: thomie, bgamari, rwbarton
      Differential Revision: https://phabricator.haskell.org/D1034
      GHC Trac Issues: #10394
    • Fumiaki Kinoshita's avatar
      base: Add instances · 97843d0b
      Fumiaki Kinoshita authored
      This patch adds following instances:
      * Foldable ZipList
      * Traversable ZipList
      * Functor Complex
      * Applicative Complex
      * Monad Complex
      * Foldable Complex
      * Traversable Complex
      * Generic1 Complex
      * Monoid a => Monoid (Identity a)
      * Storable ()
      Reviewers: ekmett, fumieval, hvr, austin
      Subscribers: thomie, #core_libraries_committee
      Projects: #core_libraries_committee
      Differential Revision: https://phabricator.haskell.org/D1049
      GHC Trac Issues: #10609
    • Ben Gamari's avatar
      Ensure DynFlags are consistent · eca9a1a1
      Ben Gamari authored
      While we have always had makeDynFlagsConsistent to enforce a variety of
      consistency invariants on DynFlags, it hasn't been widely used.
      GHC.Main, for instance, ignored it entirely. This leads to issues like
      Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency,
      leading to a perplexing crash later in compilation.
      Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags,
      closing this hole.
      Fixes #10549.
      Test Plan: Validate with T10549
      Reviewers: austin
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1128
      GHC Trac Issues: #10549
    • Simon Peyton Jones's avatar
      Test Trac #10742 · 64dba511
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      T8968-1 and -3 should pass · 294553e9
      Simon Peyton Jones authored
      See Trac #9953, comment:22.
    • Simon Peyton Jones's avatar
      Comments only · cc07c401
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Coments only · 75f5f23b
      Simon Peyton Jones authored
  2. 05 Aug, 2015 24 commits
  3. 04 Aug, 2015 2 commits
    • eir@cis.upenn.edu's avatar
      Test #9233 in perf/compiler/T9233 · b5f1c851
      eir@cis.upenn.edu authored
      Ideally, we could use Phab's numbers to set the perf
      test correctly. But even if that's not possible, then I need help
      writing my `all.T`. With the version you see here, I get the following
      Traceback (most recent call last):
        File "/Users/rae/Documents/ghc-valid/testsuite/driver/testlib.py", line 801, in do_test
          result = func(*[name,way] + args)
      TypeError: multimod_compile() takes exactly 4 arguments (6 given)
      I don't know how to fix this.
      Test Plan: validate
      Reviewers: austin, bgamari, thomie
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1129
      GHC Trac Issues: #9233
    • eir@cis.upenn.edu's avatar
      Fix #10713. · f063bd54
      eir@cis.upenn.edu authored
      When doing the apartness/flattening thing, we really only need to
      eliminate non-generative tycons, not *all* families. (Data families
      are indeed generative!)
  4. 03 Aug, 2015 5 commits
    • skvadrik's avatar
      Removed deprecated syntax for GADT constuctors. · 30c981e1
      skvadrik authored
      Old syntax was deprecated 6 years ago in this commit
      432b9c93 by simonpj:"New syntax for
      GADT-style record declarations, and associated refactoring" discussed
      in Trac #3306.
      This patch removes 2 reduce/reduce conflicts in parser. Conflicting
      productions were:
          gadt_constr -> con_list '::' sigtype
          gadt_constr -> oqtycon '{' fielddecls '}' '::' sigtype
      Recursive inlining of `con_list` and `oqtycon` helped reveal the
          gadt_constr -> '(' CONSYM ')' '::' sigtype
          gadt_constr -> '(' CONSYM ')' '{' fielddecls '}' '::' sigtype
      between two types of GADT constructors (second form stands for
      deprecated syntax).
      Test Plan: `make fasttest`, one breakage TEST="records-fail" (parse
      error instead of typecheck error due to removal of deprecated syntax).
      Updated test.
      Reviewers: simonmar, bgamari, austin, simonpj
      Reviewed By: simonpj
      Subscribers: thomie, mpickering, trofi
      Differential Revision: https://phabricator.haskell.org/D1118
      GHC Trac Issues: #3306
    • Ben Gamari's avatar
      CmmParse: Don't force alignment in memcpy-ish operations · 64b6733e
      Ben Gamari authored
      This was initially made in 681973c3.
      Here I wanted to enforce that the alignment passed to %memcpy was a
      constant expression, as this is required by LLVM. However, this breaks
      the knot-tying done in `loopDecls`, causing T8131 to hang.
      Here I remove the `seq` and mark T8131 as `expect_broken` in the case
      of the NCG, which doesn't force the alignment in this case.
      Fixes #10664.
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 7ec6ffc4
      Gabor Greif authored
    • thomasw's avatar
      Support wild cards in data/type family instances · d9d2102e
      thomasw authored
      Handle anonymous wild cards in type or data family instance
      declarations like
      unnamed type variables. For instance (pun intented):
          type family F (a :: *) (b :: *) :: *
          type instance F Int _ = Int
      Is now the same as:
          type family F (a :: *) (b :: *) :: *
          type instance F Int x = Int
      Note that unlike wild cards in partial type signatures, no errors (or
      with -XPartialTypeSignatures) are generated for these wild cards, as
      there is
      nothing interesting to report to the user, i.e. the inferred kind.
      Only anonymous wild cards are supported here, named and
      extra-constraints wild
      card are not.
      Test Plan: pass new tests
      Reviewers: goldfire, austin, simonpj, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: goldfire, thomie
      Differential Revision: https://phabricator.haskell.org/D1092
      GHC Trac Issues: #3699, #10586
    • skvadrik's avatar
      4 reduce/reduce parser conflicts resolved · 697079f1
      skvadrik authored
      As GHC documentation (section 7.4.4, Type operators) says:
      > "There is now some potential ambiguity in import and export lists;
      for example if you write import M( (+) ) do you mean the function (+)
      or the type constructor (+)? The default is the former, but with
      -XExplicitNamespaces (which is implied by -XExplicitTypeOperators) GHC
      allows you to specify the latter by preceding it with the keyword type"
      Turns out this ambiguity causes 4 of 6 reduce/reduce conflicts in GHC
      parser.  All 4 conflicts arise from a single production:
              :  qvar
              |  oqtycon
      Recursive inlining of 'qvar' and 'oqtycon' helps reveal the faulty
              | '(' QVARSYM ')'
              | '(' VARSYM ')'
              | '(' '*'    ')'
              | '(' '-'    ')'
      These productions can either be parsed as variable or type constructor,
      but variable constuctor is always preferred. My patch removes ambiguity
      while preserving the existing behaviour:
        - all unambigous productions are left as-is
        - ambigous productions for variable constuctors are left
        - ambigous productions for type constructors are removed (there's no
          way they could be triggered)
      Updated comment.
      Test Plan: Tested with 'make fasttest'
      Reviewers: austin, simonpj, trofi, bgamari, simonmar
      Reviewed By: trofi, bgamari, simonmar
      Subscribers: thomie, mpickering
      Projects: #ghc
      Differential Revision: https://phabricator.haskell.org/D1111