1. 20 Jul, 2015 8 commits
    • Luite Stegeman's avatar
      Do not treat prim and javascript imports as C imports in TH and QQ · 4cd008b6
      Luite Stegeman authored
      Reviewers: austin, hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1070
      
      GHC Trac Issues: #10638
      4cd008b6
    • Ben Gamari's avatar
      primops: Add haddocks to BCO primops · c526e095
      Ben Gamari authored
      Test Plan: none
      
      Reviewers: simonmar, austin, hvr
      
      Subscribers: hvr, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1082
      
      GHC Trac Issues: #10640
      c526e095
    • thomasw's avatar
      Support wild cards in TH splices · 49373ffe
      thomasw authored
      - Declaration splices: partial type signatures are fully supported in TH
        declaration splices.
      
        For example, the wild cards in the example below will unify with `Eq
      a`
        and `a -> a -> Bool`, as expected:
      
      ```
      [d| foo :: _ => _
          foo x y = x == y |]
      ```
      
      - Expression splices: anonymous and named wild cards are supported in
        expression signatures, but extra-constraints wild cards aren't. Just
        as is the case for regular expression signatures.
      
      ```
      [e | Just True :: _a _ |]
      ```
      
      - Typed expression splices: the same wildcards as in (untyped)
        expression splices are supported.
      
      - Pattern splices: TH doesn't support type signatures in pattern
        splices, consequently, partial type signatures aren't supported
        either.
      
      - Type splices: partial type signatures are only partially supported in
        type splices, specifically: only anonymous wild cards are allowed.
      
        So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or
        `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as
        the named wild card is treated as a type variable).
      
        Normally, named wild cards are collected before renaming a (partial)
        type signature. However, TH type splices are run during renaming, i.e.
        after the initial traversal, leading to out of scope errors for named
        wild cards. We can't just extend the initial traversal to collect the
        named wild cards in TH type splices, as we'd need to expand them,
        which is supposed to happen only once, during renaming.
      
        Similarly, the extra-constraints wild card is handled right before
        renaming too, and is therefore also not supported in a TH type splice.
        Another reason not to support extra-constraints wild cards in TH type
        splices is that a single signature can contain many TH type splices,
        whereas it mustn't contain more than one extra-constraints wild card.
        Enforcing would this be hard the way things are currently organised.
      
        Anonymous wild cards pose no problem, because they start without names
        and are given names during renaming. These names are collected right
        after renaming. The names generated for anonymous wild cards in TH
        type splices will thus be collected as well.
      
        With a more invasive refactoring of the renaming, partial type
        signatures could be fully supported in TH type splices. As only
        anonymous wild cards have been requested so far, these small changes
        satisfying this request will do for now. Also don't forget that a TH
        declaration splices support all kinds of wild cards.
      
      - Extra-constraints wild cards were silently ignored in expression and
        pattern signatures, appropriate error messages are now generated.
      
      Test Plan: run new tests
      
      Reviewers: austin, goldfire, adamgundry, bgamari
      
      Reviewed By: goldfire, adamgundry, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1048
      
      GHC Trac Issues: #10094, #10548
      49373ffe
    • Michal Terepeta's avatar
      LlvmCodeGen: add support for MO_U_Mul2 CallishMachOp · 82ffc80d
      Michal Terepeta authored
      This adds support MO_U_Mul2 to the LLVM backend by simply using 'mul'
      instruction but operating at twice the bit width (e.g., for 64 bit
      words we will generate mul that operates on 128 bits and then extract
      the two 64 bit values for the result of the CallishMachOp).
      
      Test Plan: validate
      
      Reviewers: rwbarton, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1068
      
      GHC Trac Issues: #9430
      82ffc80d
    • thomie's avatar
      Testsuite: add regression test for missing class constraint · 029367e5
      thomie authored
      The following program is accepted by ghc-7.0 to ghc-7.10, but rejected
      by ghc-6.12.3 and HEAD (and rightfully so):
      
          class Class1 a
          class Class1 a => Class2 a
          class Class2 a => Class3 a
          instance Class3 a => Class2 a
      
      The last line is missing a `Class1 a` constraint. Add a regression test
      for this (typechecker/should_fail/tcfail223).
      
      Add similar missing class constraints to T7126 and T5751. I verified
      that the these changes don't interfer with the intention of the tests
      (they still result in a loop with ghc-7.4.1).
      
      Reviewers: austin, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1078
      029367e5
    • thomie's avatar
      Testsuite: add -XUndecidableInstances to T3500a · 7f37274d
      thomie authored
      This makes the test pass again with HEAD (7.11), instead of resulting
      in:
      
        T3500a.hs:11:10: error:
            The constraint ‘C (F a)’ is no smaller than the instance head
            (Use UndecidableInstances to permit this)
            In the instance declaration for ‘C (a, b)’
      
      Test Plan: I verified that ghc-6.12.3's typechecker still loops on this
      test.
      
      Reviewers: austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1079
      7f37274d
    • thomie's avatar
      Testsuite: add ImpredicativeTypes to T7861 (#7861) · 4c96e7cf
      thomie authored
      The test was failing with:
      
          T7861: T7861.hs:15:13:
              Cannot instantiate unification variable ‘t0’
              with a type involving foralls: A a0 -> a0
                GHC doesn't yet support impredicative polymorphism
              In the first argument of ‘seq’, namely ‘f’
              In a stmt of a 'do' block: f `seq` print "Hello 2"
      
      It requires ImpredicativeTypes, at least since 7.8, because we
      instantiate seq's type (c->d->d) with f's type (c:= (forall b. a) -> a),
      which is polymorphic (it has foralls).
      
      I simplified the test a bit by removing the type synonym, and verified
      that ghc-7.6.3 still panics on this test.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1080
      
      GHC Trac Issues: #7861
      4c96e7cf
    • rwbarton's avatar
  2. 18 Jul, 2015 7 commits
  3. 17 Jul, 2015 6 commits
  4. 16 Jul, 2015 12 commits
  5. 15 Jul, 2015 7 commits