1. 30 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      b612da66
  2. 12 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Be less picky about reporing inaccessible code · 03541cba
      Simon Peyton Jones authored
      Triggered by the discussion on Trac #12466, this patch
      makes GHC less aggressive about reporting an error when
      there are insoluble Givens.
      
      Being so agressive was making some libraries fail to
      compile, and is arguably wrong in at least some cases.
      See the discussion on the ticket.
      
      Several test now pass when they failed before; see
      the files-modified list for this patch.
      03541cba
  3. 31 Aug, 2016 1 commit
  4. 21 Aug, 2016 2 commits
  5. 17 Aug, 2016 1 commit
  6. 01 Aug, 2016 1 commit
  7. 05 Jul, 2016 1 commit
    • Simon Peyton Jones's avatar
      Check generic-default method for ambiguity · 85aa6ef0
      Simon Peyton Jones authored
      Fixes Trac #7497 and #12151.   In some earlier upheaval I introduced
      a bug in the ambiguity check for genreric-default method.
      
      This patch fixes it.  But in fixing it I realised that the
      sourc-location of any such error message was bogus, so I fixed
      that too, which involved a slightly wider change; see the
      comments with TcMethInfo.
      85aa6ef0
  8. 23 Jun, 2016 1 commit
  9. 18 May, 2016 1 commit
  10. 04 May, 2016 1 commit
  11. 22 Apr, 2016 2 commits
    • Simon Peyton Jones's avatar
      Warn about simplifiable class constraints · 9421b0c7
      Simon Peyton Jones authored
      Provoked by Trac #11948, this patch adds a new warning to GHC
      
        -Wsimplifiable-class-constraints
      
      It warns if you write a class constraint in a type signature that
      can be simplified by an existing instance declaration.  Almost always
      this means you should simplify it right now; type inference is very
      fragile without it, as #11948 shows.
      
      I've put the warning as on-by-default, but I suppose that if there are
      howls of protest we can move it out (as happened for -Wredundant-constraints.
      
      It actually found an example of an over-complicated context in CmmNode.
      
      Quite a few tests use these weird contexts to trigger something else,
      so I had to suppress the warning in those.
      
      The 'haskeline' library has a few occurrences of the warning (which
      I think should be fixed), so I switched it off for that library in
      warnings.mk.
      
      The warning itself is done in TcValidity.check_class_pred.
      
      HOWEVER, when type inference fails we get a type error; and the error
      suppresses the (informative) warning.  So as things stand, the warning
      only happens when it doesn't cause a problem.  Not sure what to do
      about this, but this patch takes us forward, I think.
      9421b0c7
    • Simon Peyton Jones's avatar
      Do not use defaulting in ambiguity check · edf54d72
      Simon Peyton Jones authored
      This fixes Trac #11947.  See TcSimplify
      Note [No defaulting in the ambiguity check]
      edf54d72
  12. 11 Apr, 2016 1 commit
    • Rik Steenkamp's avatar
      Fix a closed type family error message · 46e8f199
      Rik Steenkamp authored
      Now we check whether a closed type family's equation is headed with
      the correct type before we kind-check the equation.
      
      Also, instead of "expected only no parameters" we now generate the
      message "expected no parameters".
      
      Fixes #11623.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2089
      
      GHC Trac Issues: #11623
      46e8f199
  13. 07 Apr, 2016 1 commit
  14. 26 Mar, 2016 1 commit
  15. 21 Mar, 2016 1 commit
  16. 20 Mar, 2016 1 commit
  17. 29 Feb, 2016 1 commit
  18. 17 Feb, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Fix #11313. · a6152159
      eir@cis.upenn.edu authored
      Previously, we looked through synonyms when counting arguments,
      but that's a bit silly.
      a6152159
    • thomie's avatar
      Testsuite: delete compiler_lt/le/gt/ge setup functions · 6f25fb32
      thomie authored
      Since we're not consisently keeping track of which tests should pass
      with which compiler versions, there is no point in keeping these
      functions.
      
      Update submodules containers, hpc and stm.
      6f25fb32
  19. 16 Feb, 2016 1 commit
    • Yuras's avatar
      Suggest candidate instances in error message · 5fc06b97
      Yuras authored
      See Trac #9611. In "No instance..." error message we suggest instances
      for other types with the same occ name. It is usefull e.g. when we have
      two different versions of the same package installed.
      
      Test Plan: typecheck/should_fail/tcfail224
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1919
      
      GHC Trac Issues: #9611
      5fc06b97
  20. 15 Feb, 2016 1 commit
  21. 10 Feb, 2016 1 commit
  22. 23 Jan, 2016 1 commit
  23. 21 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Strip casts in checkValidInstHead · b2e6350f
      Simon Peyton Jones authored
      This patch addresses Trac #11464.
      
      The fix is a bit crude (traverse the type to remove CastTys),
      but it's also simple.
      
      See Note [Casts during validity checking] in TcValidity
      b2e6350f
  24. 15 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11355. · e6ca9300
      eir@cis.upenn.edu authored
      Previously, the check for impredicative type applications was
      in the wrong spot.
      
      Test case: typecheck/should_fail/T11355
      e6ca9300
  25. 14 Jan, 2016 1 commit
  26. 07 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Turn AThing into ATcTyCon, in TcTyThing · a5cea73c
      Simon Peyton Jones authored
      This change tidies up and simplifies (a bit) the knot-tying
      when kind-checking groups of type and class declarations.
      
      The trouble (shown by Trac #11356) was that we wanted an error message
      (a kind-mismatch) that involved a type mentioned a (AThing k), which
      blew up.
      
      Since we now seem to have TcTyCons, I decided to use them here.
      It's still not great, but it's easier to understand and more robust.
      a5cea73c
  27. 05 Jan, 2016 1 commit
    • Joachim Breitner's avatar
      Add (failing) test case for #11347 · 1a8b752d
      Joachim Breitner authored
      Unfortunately, I could not add the expected error message, so if someone
      accidentally fixes this bug, this test will still be failing (no harm).
      But maybe someone stumbles over it then and can update the expected
      output.
      1a8b752d
  28. 26 Dec, 2015 1 commit
  29. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
  30. 23 Dec, 2015 1 commit
  31. 21 Dec, 2015 2 commits
  32. 23 Nov, 2015 1 commit
  33. 16 Nov, 2015 2 commits
  34. 20 Oct, 2015 1 commit
  35. 21 Sep, 2015 1 commit
    • 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