1. 26 Sep, 2015 2 commits
    • Ömer Sinan Ağacan's avatar
      reify associated types when reifying typeclasses(#10891) · b4d43b4e
      Ömer Sinan Ağacan authored
      As reported in Trac #10891, Template Haskell's `reify` was not
      generating Decls for associated types. This patch fixes that.
      
      Note that even though `reifyTyCon` function used in this patch returns
      some type instances, I'm ignoring that.
      
      Here's an example of how associated types are encoded with this patch:
      
      (Simplified representation)
      
          class C a where
            type F a :: *
      
          -->
      
          OpenTypeFamilyD "F" ["a"]
      
      With default type instances:
      
          class C a where
            type F a :: *
            type F a = a
      
          -->
      
          OpenTypeFamilyD "F" ["a"]
          TySynInstD "F" (TySynEqn [VarT "a"] "a")
      
      Test Plan:
      This patch was already reviewed and even merged. The patch is later
      reverted because apparently it broke the build some time between the
      validation of this patch and merge. Creating this new ticket to fix the
      validation.
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1277
      
      GHC Trac Issues: #10891
      b4d43b4e
    • Ben Gamari's avatar
      rts: Clean up whitespace in Trace.h · 988b2baa
      Ben Gamari authored
      988b2baa
  2. 25 Sep, 2015 5 commits
  3. 24 Sep, 2015 5 commits
  4. 23 Sep, 2015 9 commits
  5. 22 Sep, 2015 4 commits
  6. 21 Sep, 2015 15 commits
    • Edward Z. Yang's avatar
      Remove (now bogus) assert. · 83e23c1a
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      83e23c1a
    • Ben Gamari's avatar
      TcDeriv: Use a NameEnv instead of association list · 5a8b055e
      Ben Gamari authored
      It's unlikely that these lists would have become very large but
      nevertheless this is an easy and worthwhile change.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D1265
      5a8b055e
    • niteria's avatar
      Remove graphFromVerticesAndAdjacency · 07f6418e
      niteria authored
      It's not used anywhere.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D1266
      07f6418e
    • Edward Z. Yang's avatar
      Fix build failure, I think. · d516d2e1
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d516d2e1
    • Edward Z. Yang's avatar
      Unify hsig and hs-boot; add preliminary "hs-boot" merging. · 06d46b1e
      Edward Z. Yang authored
      This patch drops the file level distinction between hs-boot and hsig;
      we figure out which one we are compiling based on whether or not there
      is a corresponding hs file lying around.
      
      To make the "import A" syntax continue to work for bare hs-boot
      files, we also introduce hs-boot merging, which takes an A.hi-boot
      and converts it to an A.hi when there is no A.hs file in scope.
      This will be generalized in Backpack to merge multiple A.hi files together;
      which means we can jettison the "load multiple interface files" functionality.
      
      This works automatically for --make, but for one-shot compilation
      we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
      from a local A.hi-boot file; Backpack will extend this mechanism further.
      
      Has Haddock submodule update to deal with change in msHsFilePath behavior.
      
          - This commit drops support for the hsig extension. Can
            we support it?  It's annoying because the finder code is
            written with the assumption that where there's an hs-boot
            file, there's always an hs file too.  To support hsig, you'd
            have to probe two locations.  Easier to just not support it.
      
          - #10333 affects us, modifying an hs-boot still doesn't trigger
            recomp.
      
          - See compiler/main/Finder.hs: this diff is very skeevy, but
            it seems to work.
      
          - This code cunningly doesn't drop hs-boot files from the
            "drop hs-boot files" module graph, if they don't have a
            corresponding hs file.  I have no idea if this actually is useful.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, spinda
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1098
      06d46b1e
    • Edward Z. Yang's avatar
      09d214dc
    • Edward Z. Yang's avatar
      3f13c20e
    • eir@cis.upenn.edu's avatar
      `_ <- mapM` --> `mapM_` · c234acbe
      eir@cis.upenn.edu authored
      Thanks for the suggestion, Austin. Just missed that while making
      a bunch of similar changes.
      c234acbe
    • eir@cis.upenn.edu's avatar
      Refactor BranchLists. · cd2840a7
      eir@cis.upenn.edu authored
      Now we use Array to store branches. This makes sense because we often
      have to do random access (once inference is done). This also vastly
      simplifies the awkward BranchList type.
      
      This fixes #10837 and updates submodule utils/haddock.
      cd2840a7
    • eir@cis.upenn.edu's avatar
      Run simplifier only when the env is clean. · 8e8b9ed9
      eir@cis.upenn.edu authored
      This fixes #10896. In the indexed-types/should_fail/BadSock test,
      there is a bad type definition. This gets type-checked, an error
      gets reported, but then **GHC keeps going**. Later, when
      running the simplifier to do an ambiguity check, the bad type
      environment causes GHC to fall over. My solution: only run the
      simplifier in a clean, error-free type environment.
      
      A downside of this is that fewer error messages are reported.
      This makes me a bit sad, but I'm not sure how to avoid the problem.
      Suggestions welcome.
      8e8b9ed9
    • eir@cis.upenn.edu's avatar
      Perform a validity check on assoc type defaults. · e27b267f
      eir@cis.upenn.edu authored
      This fixes #10817 and #10899. A knock-on effect is that we must
      now remember locations of associated type defaults for error
      messages during validity checking. This isn't too bad, but it
      increases the size of the diff somewhat.
      
      Test cases: indexed-types/should_fail/T108{17,99}
      e27b267f
    • eir@cis.upenn.edu's avatar
      Slightly better `Coercible` errors. · 2f9809ef
      eir@cis.upenn.edu authored
      This makes two real changes:
       - Equalities like (a ~R [a]) really *are* insoluble. Previously,
         GHC refused to give up when an occurs check bit on a representational
         equality. But for datatypes, it really should bail.
      
       - Now, GHC will sometimes report an occurs check error (in cases above)
         for representational equalities. Previously, it never did.
      
      This "fixes" #10715, where by "fix", I mean clarifies the error message.
      It's unclear how to do more to fix that ticket.
      
      Test cases: typecheck/should_fail/T10715{,b}
      2f9809ef
    • eir@cis.upenn.edu's avatar
      Fix typo in test for #10347. · cbcad859
      eir@cis.upenn.edu authored
      Thanks to Gabor Greif for spotting the mistake.
      cbcad859
    • eir@cis.upenn.edu's avatar
      Small improvement in pretty-printing constructors. · 6a209205
      eir@cis.upenn.edu authored
      This fixes #10810 by cleaning up pretty-printing of constructor
      declarations. This change also removes a (in my opinion) deeply
      bogus orphan instance OutputableBndr [Located name], making
      HsDecls now a non-orphan module. Yay all around.
      
      Test case: th/T10810
      6a209205
    • eir@cis.upenn.edu's avatar
      Re-polish error messages around injective TFs. · 93fafe05
      eir@cis.upenn.edu authored
      The previous message was wrong, as pointed out by Jan Stolarek.
      93fafe05