1. 12 Oct, 2019 1 commit
  2. 08 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Solve constraints from top-level groups sooner · 9612e91c
      Richard Eisenberg authored
      Previously, all constraints from all top-level groups (as
      separated by top-level splices) were lumped together and solved
      at the end. This could leak metavariables to TH, though, and
      that's bad. This patch solves each group's constraints before
      running the next group's splice.
      
      Naturally, we now report fewer errors in some cases.
      
      One nice benefit is that this also fixes #11680, but in a much
      simpler way than the original fix for that ticket. Admittedly,
      the error messages degrade just a bit from the fix from #11680
      (previously, we informed users about variables that will be
      brought into scope below a top-level splice, and now we just
      report an out-of-scope error), but the amount of complexity
      required throughout GHC to get that error was just not worth it.
      
      This patch thus reverts much of
      f93c9517.
      
      Fixes #16980
      
      Test cases: th/T16980{,a}
      9612e91c
  3. 03 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Improve documentation around empty tuples/lists · 6655ec73
      Richard Eisenberg authored
      This patch also changes the way we handle empty lists, simplifying
      them somewhat. See Note [Empty lists]. Previously, we had to
      special-case empty lists in the type-checker. Now no more!
      
      Finally, this patch improves some documentation around the ir_inst
      field used in the type-checker.
      
      This breaks a test case, but I really think the problem is #17251,
      not really related to this patch.
      
      Test case: typecheck/should_compile/T13680
      6655ec73
  4. 28 Sep, 2019 1 commit
  5. 17 Sep, 2019 1 commit
  6. 16 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      Encode shape information in `PmOracle` · 7915afc6
      Sebastian Graf authored
      Previously, we had an elaborate mechanism for selecting the warnings to
      generate in the presence of different `COMPLETE` matching groups that,
      albeit finely-tuned, produced wrong results from an end user's
      perspective in some cases (#13363).
      
      The underlying issue is that at the point where the `ConVar` case has to
      commit to a particular `COMPLETE` group, there's not enough information
      to do so and the status quo was to just enumerate all possible complete
      sets nondeterministically.  The `getResult` function would then pick the
      outcome according to metrics defined in accordance to the user's guide.
      But crucially, it lacked knowledge about the order in which affected
      clauses appear, leading to the surprising behavior in #13363.
      
      In !1010 we taught the term oracle to reason about literal values a
      variable can certainly not take on. This MR extends that idea to
      `ConLike`s and thereby fixes #13363: Instead of committing to a
      particular `COMPLETE` group in the `ConVar` case, we now split off the
      matching constructor incrementally and record the newly covered case as
      a refutable shape in the oracle. Whenever the set of refutable shapes
      covers any `COMPLETE` set, the oracle recognises vacuosity of the
      uncovered set.
      
      This patch goes a step further: Since at this point the information
      in value abstractions is merely a cut down representation of what the
      oracle knows, value abstractions degenerate to a single `Id`, the
      semantics of which is determined by the oracle state `Delta`.
      Value vectors become lists of `[Id]` given meaning to by a single
      `Delta`, value set abstractions (of which the uncovered set is an
      instance) correspond to a union of `Delta`s which instantiate the
      same `[Id]` (akin to models of formula).
      
      Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149
      
      -------------------------
      Metric Decrease:
          ManyAlternatives
          T11195
      -------------------------
      7915afc6
  7. 26 Jul, 2019 1 commit
  8. 05 Jul, 2019 1 commit
  9. 03 Jul, 2019 1 commit
  10. 02 Jul, 2019 1 commit
  11. 12 Jun, 2019 1 commit
  12. 10 Jun, 2019 1 commit
  13. 21 May, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16666 by parenthesizing contexts in Convert · 4a6c8436
      Ryan Scott authored
      Most places where we convert contexts in `Convert` are actually in
      positions that are to the left of some `=>`, such as in superclasses
      and instance contexts. Accordingly, these contexts need to be
      parenthesized at `funPrec`. To accomplish this, this patch changes
      `cvtContext` to require a precedence argument for the purposes of
      calling `parenthesizeHsContext` and adjusts all `cvtContext` call
      sites accordingly.
      4a6c8436
  14. 14 May, 2019 1 commit
  15. 08 Apr, 2019 1 commit
  16. 01 Apr, 2019 1 commit
  17. 22 Mar, 2019 1 commit
  18. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  19. 15 Mar, 2019 1 commit
  20. 08 Mar, 2019 1 commit
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored
      GHC represents String literals as ByteString internally for efficiency
      reasons. However, until now it wasn't possible to efficiently create
      large string literals with TH (e.g. to embed a file in a binary, cf #14741):
      TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
      into a ByteString.
      
      This patch adds the possibility to efficiently create a "string" literal
      from raw bytes. We get the following compile times for different sizes
      of TH created literals:
      
      || Size || Before || After  || Gain ||
      || 30K  || 2.307s || 2.299  || 0%   ||
      || 3M   || 3.073s || 2.400s || 21%  ||
      || 30M  || 8.517s || 3.390s || 60%  ||
      
      Ticket #14741 can be fixed if the original code uses this new TH feature.
      224a6b86
  21. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
        that only splits invisible `forall`s. This function is used in
        certain places (e.g., in instance declarations) to ensure that GHC
        doesn't try to split visible `forall`s (e.g., if it tried splitting
        `instance forall a -> Show (Blah a)`, then GHC would mistakenly
        allow that declaration!)
      
      This also updates Template Haskell by introducing a new `ForallVisT`
      constructor to `Type`.
      
      Fixes #16326. Also fixes #15658 by documenting this feature in the
      users' guide.
      c26d299d
  22. 24 Feb, 2019 1 commit
  23. 12 Feb, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16293 by cleaning up Proxy# infelicities · 012257c1
      Ryan Scott authored
      This bug fixes three problems related to `Proxy#`/`proxy#`:
      
      1. Reifying it with TH claims that the `Proxy#` type constructor has
         two arguments, but that ought to be one for consistency with
         TH's treatment for other primitive type constructors like `(->)`.
         This was fixed by just returning the number of
         `tyConVisibleTyVars` instead of using `tyConArity` (which includes
         invisible arguments).
      2. The role of `Proxy#`'s visible argument was hard-coded as nominal.
         Easily fixed by changing it to phantom.
      3. The visibility of `proxy#`'s kind argument was specified, which
         is different from the `Proxy` constructor (which treats it as
         inferred). Some minor refactoring in `proxyHashId` fixed ths up.
      
         Along the way, I had to introduce a `mkSpecForAllTy` function, so
         I did some related Haddock cleanup in `Type`, where that function
         lives.
      012257c1
  24. 10 Feb, 2019 1 commit
    • Matthew Pickering's avatar
      Capture and simplify constraints arising from running typed splices · a48753bd
      Matthew Pickering authored
      This fixes a regression caused by #15471 where splicing in a trivial
      program such as `[|| return () ||]` would fail as the dictionary for
      `return` would never get bound in the module containing the splice.
      
      Arguably this is symptomatic of a major problem affecting TTH where we
      serialise renamed asts and then retype check them. The reference to the
      dictionary should be fully determined at the quote site so that splicing
      doesn't have to solve any implicits at all. It's a coincidence this
      works due to coherence but see #15863 and #15865 for examples where
      things do go very wrong.
      
      Fixes #16195
      a48753bd
  25. 08 Feb, 2019 1 commit
  26. 30 Jan, 2019 3 commits
  27. 28 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Use sigPrec in more places in Convert and HsUtils · b1e569a5
      Ryan Scott authored
      Trac #16183 was caused by TH conversion (in `Convert`) not properly
      inserting parentheses around occurrences of explicit signatures where
      appropriate, such as in applications, function types, and type family
      equations. Solution: use `parenthesizeHsType sigPrec` in these
      places. While I was in town, I also updated `nlHsFunTy` to do the
      same thing.
      b1e569a5
  28. 23 Jan, 2019 1 commit
  29. 21 Jan, 2019 1 commit
  30. 11 Jan, 2019 1 commit
    • Matthew Pickering's avatar
      Run typed splices in the zonker · c2455e64
      Matthew Pickering authored
      Summary:
      This fixes #15471
      
      In the typechecker we check that the splice has the right type but we
      crucially don't zonk the generated expression. This is because we might
      end up unifying type variables from outer scopes later on.
      
      Reviewers: simonpj, goldfire, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15471
      
      Differential Revision: https://phabricator.haskell.org/D5286
      c2455e64
  31. 06 Jan, 2019 1 commit
  32. 03 Jan, 2019 1 commit
    • My Nguyen's avatar
      Visible kind application · 17bd1635
      My Nguyen authored
      Summary:
      This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
      It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
      written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
      application, just like in term-level.
      
      There are a few remaining issues with this patch, as documented in
      ticket #16082.
      
      Includes a submodule update for Haddock.
      
      Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
      
      Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
      
      Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
      
      GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
      
      Differential Revision: https://phabricator.haskell.org/D5229
      17bd1635
  33. 29 Dec, 2018 1 commit
  34. 24 Dec, 2018 1 commit
  35. 22 Dec, 2018 1 commit
  36. 11 Dec, 2018 1 commit
  37. 07 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Wibble to Taming the Kind Inference Monster · 5b7ca039
      Simon Peyton Jones authored
      I had allowed rename/should_fail/T15828 (Trac #15828) to regress a bit.
      The main payload of this patch is to fix that problem, at the cost of
      more contortions in checkConsistentFamInst.  Oh well, at least they are
      highly localised.
      
      I also update the -ddump-types code in TcRnDriver to print out some
      more expicit information about each type constructor, thus instead of
      
         DF{3} :: forall k. * -> k -> *
      
      we get
      
         data family DF{3} :: forall k. * -> k -> *
      
      Remember, this is debug-printing only.  This change is the reason
      that so many .stderr files change.
      5b7ca039
  38. 03 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix embarrassing infinite loop in pprParendType · 89d80921
      Ryan Scott authored
      Summary:
      `pprParendType` was missing an explicit case for
      `EqualityT`, which caused it to fall through to a catch-all case
      that invokes `ppr`. But `ppr` itself does not have a case for a
      partial application of `EqualityT`, so //it// falls back to
      `pprParendType`, resulting in an infinite loop!
      
      The fix is simple: add a case for `EqualityT` in `pprParendType`.
      While I was in the neighborhood, I removed the catch-call case in
      `pprParendType` to make this sort of mistake less likely to happen
      in the future.
      
      Test Plan: make test TEST=T15985
      
      Reviewers: bgamari, monoidal, simonpj
      
      Reviewed By: monoidal, simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15985
      
      Differential Revision: https://phabricator.haskell.org/D5403
      89d80921