1. 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
  2. 20 Mar, 2019 4 commits
  3. 17 Mar, 2019 1 commit
    • Ben Gamari's avatar
      ghc-heap: Introduce closureSize · cb61371e
      Ben Gamari authored
      This function allows the user to compute the (non-transitive) size of a
      heap object in words. The "closure" in the name is admittedly confusing
      but we are stuck with this nomenclature at this point.
      cb61371e
  4. 16 Mar, 2019 3 commits
    • Ben Gamari's avatar
      compiler: Disable atomic renaming on Windows · 1c1b63d6
      Ben Gamari authored
      As discussed in #16450, this feature regresses CI on Windows, causing
      non-deterministic failures due to missing files.
      1c1b63d6
    • Simon Peyton Jones's avatar
      Add location to the extra-constraints wildcard · 600a1ac3
      Simon Peyton Jones authored
      The extra-constraints wildcard had lost its location
      (issue #16431).
      
      Happily this is easy to fix.  Lots of error improvements.
      600a1ac3
    • Simon Peyton Jones's avatar
      Improve error recovery in the typechecker · 4927117c
      Simon Peyton Jones authored
      Issue #16418 showed that we were carrying on too eagerly after a bogus
      type signature was identified (a bad telescope in fact), leading to a
      subsequent crash.
      
      This led me in to a maze of twisty little passages in the typechecker's
      error recovery, and I ended up doing some refactoring in TcRnMonad.
      Some specfifics
      
      * TcRnMonad.try_m is now called attemptM.
      
      * I switched the order of the result pair in tryTc,
        to make it consistent with other similar functions.
      
      * The actual exception used in the Tc monad is irrelevant so,
        to avoid polluting type signatures, I made tcTryM, a simple
        wrapper around tryM, and used it.
      
      The more important changes are in
      
      * TcSimplify.captureTopConstraints, where we should have been calling
        simplifyTop rather than reportUnsolved, so that levity defaulting
        takes place properly.
      
      * TcUnify.emitResidualTvConstraint, where we need to set the correct
        status for a new implication constraint.  (Previously we ended up
        with an Insoluble constraint wrapped in an Unsolved implication,
        which meant that insolubleWC gave the wrong answer.
      4927117c
  5. 15 Mar, 2019 4 commits
    • Peter Trommler's avatar
      PPC NCG: Use liveness information in CmmCall · 83e09d3c
      Peter Trommler authored
      We make liveness information for global registers
      available on `JMP` and `BCTR`, which were the last instructions
      missing. With complete liveness information we do not need to
      reserve global registers in `freeReg` anymore. Moreover we
      assign R9 and R10 to callee saves registers.
      
      Cleanup by removing `Reg_Su`, which was unused, from `freeReg`
      and removing unused register definitions.
      
      The calculation of the number of floating point registers is too
      conservative. Just follow X86 and specify the constants directly.
      
      Overall on PowerPC this results in 0.3 % smaller code size in nofib
      while runtime is slightly better in some tests.
      83e09d3c
    • Simon Peyton Jones's avatar
      Report better suggestion for GADT data constructor · 97032ed9
      Simon Peyton Jones authored
      This addresses issue #16427. An easy fix.
      97032ed9
    • Ryan Scott's avatar
      Update Trac ticket URLs to point to GitLab · 610ec224
      Ryan Scott authored
      This moves all URL references to Trac tickets to their corresponding
      GitLab counterparts.
      610ec224
    • Ryan Scott's avatar
      Remove the GHCi debugger's panicking isUnliftedType check · 8162eab2
      Ryan Scott authored
      The GHCi debugger has never been that robust in the face of
      higher-rank types, or even types that are _interally_ higher-rank,
      such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
      however, things became even worse, as the debugger would start to
      _panic_ when a user tries passing the name of a higher-rank thing
      to `:print`. This all ties back to a strange `isUnliftedType` check
      in `Debugger` that was mysteriously added 11 years ago
      (in commit 4d71f5ee) with no
      explanation whatsoever.
      
      After some experimentation, no one is quite sure what this
      `isUnliftedType` check is actually accomplishing. The test suite
      still passes if it's removed, and I am unable to observe any
      differences in debugger before even with data types that _do_ have
      fields of unlifted types (e.g., `data T = MkT Int#`). Given that
      this is actively causing problems (see #14828), the prudent thing
      to do seems to be just removing this `isUnliftedType` check, and
      waiting to see if anyone shouts about it. This patch accomplishes
      just that.
      
      Note that this patch fix the underlying issues behind #14828, as the
      debugger will still print unhelpful info if you try this:
      
      ```
      λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
      λ> :print f
      f = (_t1::t1)
      ```
      
      But fixing this will require much more work, so let's start with the
      simple stuff for now.
      8162eab2
  6. 13 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16411 by making dataConCannotMatch aware of (~~) · 36546a43
      Ryan Scott authored
      The `dataConCannotMatch` function (which powers the
      `-Wpartial-fields` warning, among other things) had special reasoning
      for explicit equality constraints of the form `a ~ b`, but it did
      not extend that reasoning to `a ~~ b` constraints, leading to #16411.
      Easily fixed.
      36546a43
  7. 12 Mar, 2019 2 commits
  8. 11 Mar, 2019 1 commit
  9. 09 Mar, 2019 4 commits
  10. 08 Mar, 2019 4 commits
    • Roland Senn's avatar
    • 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
    • Simon Peyton Jones's avatar
      Use captureTopConstraints in TcRnDriver calls · 5be7ad78
      Simon Peyton Jones authored
      Trac #16376 showed the danger of failing to report an error
      that exists only in the unsolved constraints, if an exception
      is raised (via failM).
      
      Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
      did just that -- i.e. it found errors in the constraints, and
      called failM to avoid a misleading cascade.
      
      So we need to be sure to call captureTopConstraints to report
      those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
      in TcRnDriver.tcRnType.
      
      As a result the error messages from test T13466 improved slightly,
      a happy outcome.
      5be7ad78
    • Sebastian Graf's avatar
      Always do the worker/wrapper split for NOINLINEs · 1675d40a
      Sebastian Graf authored
      Trac #10069 revealed that small NOINLINE functions didn't get split
      into worker and wrapper. This was due to `certainlyWillInline`
      saying that any unfoldings with a guidance of `UnfWhen` inline
      unconditionally. That isn't the case for NOINLINE functions, so we
      catch this case earlier now.
      
      Nofib results:
      
      --------------------------------------------------------------------------------
              Program         Allocs    Instrs
      --------------------------------------------------------------------------------
       fannkuch-redux          -0.3%      0.0%
                   gg          +0.0%     +0.1%
             maillist          -0.2%     -0.2%
              minimax           0.0%     -0.8%
      --------------------------------------------------------------------------------
                  Min          -0.3%     -0.8%
                  Max          +0.0%     +0.1%
       Geometric Mean          -0.0%     -0.0%
      
      Fixes #10069.
      
      -------------------------
      Metric Increase:
          T9233
      -------------------------
      1675d40a
  11. 07 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16391 by using occCheckExpand in TcValidity · 068b7e98
      Ryan Scott authored
      The type-variables-escaping-their-scope-via-kinds check in
      `TcValidity` was failing to properly expand type synonyms, which led
      to #16391. This is easily fixed by using `occCheckExpand` before
      performing the validity check.
      
      Along the way, I refactored this check out into its own function,
      and sprinkled references to Notes to better explain all of the moving
      parts. Many thanks to @simonpj for the suggestions.
      
      Bumps the haddock submodule.
      068b7e98
  12. 06 Mar, 2019 2 commits
    • Ryan Scott's avatar
      Fix #16385 by appending _maybe to a use of lookupGlobalOcc · 78dd04f9
      Ryan Scott authored
      `instance forall c. c` claimed that `c` was out of scope because the
      renamer was invoking `lookupGlobalOcc` on `c` (in
      `RnNames.getLocalNonValBinders`) without binding `c` first. To avoid
      this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c`
      instead, and if that returns `Nothing`, then bail out, resulting
      in a better error message.
      78dd04f9
    • Ben Gamari's avatar
      Rip out object splitting · 37f257af
      Ben Gamari authored
      The splitter is an evil Perl script that processes assembler code.
      Its job can be done better by the linker's --gc-sections flag. GHC
      passes this flag to the linker whenever -split-sections is passed on
      the command line.
      
      This is based on @DemiMarie's D2768.
      
      Fixes Trac #11315
      Fixes Trac #9832
      Fixes Trac #8964
      Fixes Trac #8685
      Fixes Trac #8629
      37f257af
  13. 05 Mar, 2019 2 commits
    • Krzysztof Gogolewski's avatar
      Fix map/coerce rule for newtypes with wrappers · 646b6dfb
      Krzysztof Gogolewski authored
      This addresses Trac #16208 by marking newtype wrapper
      unfoldings as compulsory.
      
      Furthermore, we can remove the special case for newtypes
      in exprIsConApp_maybe (introduced in 7833cf40).
      646b6dfb
    • Simon Peyton Jones's avatar
      Be more careful when naming TyCon binders · 80dfcee6
      Simon Peyton Jones authored
      This patch fixes two rather gnarly test cases:
        * Trac #16342 (mutual recursion)
          See Note [Tricky scoping in generaliseTcTyCon]
      
        * Trac #16221 (shadowing)
          See Note [Unification variables need fresh Names]
      
      The main changes are:
      
      * Substantial reworking of TcTyClsDecls.generaliseTcTyCon
        This is the big change, and involves the rather tricky
        function TcHsSyn.zonkRecTyVarBndrs.
      
        See Note [Inferring kinds for type declarations] and
        Note [Tricky scoping in generaliseTcTyCon] for the details.
      
      * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now
        allocate /freshly-named/ unification variables. Indeed, more
        generally, unification variables are always fresh; see
        Note [Unification variables need fresh Names] in TcMType
      
      * Clarify the role of tcTyConScopedTyVars.
        See Note [Scoped tyvars in a TcTyCon] in TyCon
      
      As usual, this dragged in some more refactoring:
      
      * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise
      
      * I renamed checkValidTelescope to checkTyConTelescope;
        it's only used on TyCons, and indeed takes a TyCon as argument.
      
      * I folded the slightly-mysterious reportFloatingKvs into
        checkTyConTelescope. (Previously all its calls immediately
        followed a call to checkTyConTelescope.)  It makes much more
        sense there.
      
      * I inlined some called-once functions to simplify
        checkValidTyFamEqn. It's less spaghetti-like now.
      
      * This patch also fixes Trac #16251.  I'm not quite sure why #16251
        went wrong in the first place, nor how this patch fixes it, but
        hey, it's good, and life is short.
      80dfcee6
  14. 04 Mar, 2019 2 commits
  15. 01 Mar, 2019 2 commits
    • Alec Theriault's avatar
      Lexer: turn some fatal errors into non-fatal ones · f37efb11
      Alec Theriault authored
      The following previously fatal lexer errors are now non-fatal:
      
        * errors about enabling `LambdaCase`
        * errors about enabling `NumericUnderscores`
        * errors about having valid characters in primitive strings
      
      See #16270
      f37efb11
    • 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
  16. 27 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Treat kind/type variables identically, demolish FKTV · 5bc195b1
      Vladislav Zavialov authored
      Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
      Fixes Trac #16334, Trac #16315
      
      With this patch, scoping rules for type and kind variables have been
      unified: kind variables no longer receieve special treatment. This
      simplifies both the language and the implementation.
      
      User-facing changes
      -------------------
      
      * Kind variables are no longer implicitly quantified when an explicit
        forall is used:
      
          p ::             Proxy (a :: k)    -- still accepted
          p :: forall k a. Proxy (a :: k)    -- still accepted
          p :: forall   a. Proxy (a :: k)    -- no longer accepted
      
        In other words, now we adhere to the "forall-or-nothing" rule more
        strictly.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * The -Wimplicit-kind-vars warning has been deprecated.
      
      * Kind variables are no longer implicitly quantified in constructor
        declarations:
      
          data T a        = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- no longer accepted
          data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- still accepted
      
        Related function: RnTypes.extractRdrKindSigVars
      
      * Implicitly quantified kind variables are no longer put in front of
        other variables:
      
          f :: Proxy (a :: k) -> Proxy (b :: j)
      
          f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b   -- old order
          f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b   -- new order
      
        This is a breaking change for users of TypeApplications. Note that
        we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
        See "Ordering of specified variables" in the User's Guide.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * In type synonyms and type family equations, free variables on the RHS
        are no longer implicitly quantified unless used in an outermost kind
        annotation:
      
          type T = Just (Nothing :: Maybe a)         -- no longer accepted
          type T = Just Nothing :: Maybe (Maybe a)   -- still accepted
      
        The latter form is a workaround due to temporary lack of an explicit
        quantification method. Ideally, we would write something along these
        lines:
      
          type T @a = Just (Nothing :: Maybe a)
      
        Related function: RnTypes.extractHsTyRdrTyVarsKindVars
      
      * Named wildcards in kinds are fixed (Trac #16334):
      
          x :: (Int :: _t)    -- this compiles, infers (_t ~ Type)
      
        Related function: RnTypes.partition_nwcs
      
      Implementation notes
      --------------------
      
      * One of the key changes is the removal of FKTV in RnTypes:
      
        - data FreeKiTyVars = FKTV { fktv_kis    :: [Located RdrName]
        -                          , fktv_tys    :: [Located RdrName] }
        + type FreeKiTyVars = [Located RdrName]
      
        We used to keep track of type and kind variables separately, but
        now that they are on equal footing when it comes to scoping, we
        can put them in the same list.
      
      * extract_lty and family are no longer parametrized by TypeOrKind,
        as we now do not distinguish kind variables from type variables.
      
      * PatSynExPE and the related Note [Pattern synonym existentials do not scope]
        have been removed (Trac #16315). With no implicit kind quantification,
        we can no longer trigger the error.
      
      * reportFloatingKvs and the related Note [Free-floating kind vars]
        have been removed. With no implicit kind quantification,
        we can no longer trigger the error.
      5bc195b1
  17. 24 Feb, 2019 5 commits
    • Alexandre R. Baldé's avatar
      base: Allow fusion for zip7 and related · 9059343e
      Alexandre R. Baldé authored
      Fixes #14037.
      
      Metric Decrease:
          T9872b
          T9872d
      
      Reviewers: bgamari, simonpj, hvr
      
      Reviewed By: simonpj
      
      Subscribers: AndreasK, simonpj, osa1, dfeuer, rwbarton, carter
      
      GHC Trac Issues: #14037
      
      Differential Revision: https://phabricator.haskell.org/D5249
      9059343e
    • Sebastian Graf's avatar
      Include closure header size in StgLamLift's estimations · b85068f6
      Sebastian Graf authored
      While playing around with late lambda lifting, I realised that
      StgLamLift.Analysis doesn't consider the removed closure header in its
      allocation estimations.
      
      That's because contrary to what I thought, the total word count returned
      by `mkVirtHeapOffsets` doesn't include the size of the closure header.
      
      We just add the header size manually now.
      b85068f6
    • Herbert Valerio Riedel's avatar
      Fix regression incorrectly advertising TH support · ee284b85
      Herbert Valerio Riedel authored
      `--supported-languages` must only advertise language extensions
      which are supported by the compiler in order for tooling such
      as Cabal relying on this signalling not to behave incorrectly.
      
      Fixes #16331
      ee284b85
    • Vladislav Zavialov's avatar
      Expression/command ambiguity resolution · e61f6e35
      Vladislav Zavialov authored
      This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
      introducing a new ambiguity resolution system in the parser.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a command:
      
      	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
      	proc x -> do { (stuff) }        -- 'stuff' is a command
      
      Until we encounter arrow syntax (-<) we don't know whether to parse
      'stuff' as an expression or a command.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
      
      This meant polluting 'HsExpr' with command-related constructors. In
      other words, limitations of the parser were affecting the AST, and
      all other code (the renamer, the typechecker) had to deal with these
      extra constructors by panicking.
      
      We fix this abstraction leak by parsing into an intermediate
      representation, 'ExpCmd':
      
      	data ExpCmdG b where
      	  ExpG :: ExpCmdG HsExpr
      	  CmdG :: ExpCmdG HsCmd
      
      	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
      
      	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
      	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
      	checkExp f = f ExpG  -- interpret as an expression
      	checkCmd f = f CmdG  -- interpret as a command
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/command ambiguity.
      
      Future work: apply the same principles to the expression/pattern
      ambiguity.
      e61f6e35
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
      
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      
      See Note [Function types] in TyCoRep.
      
      There are lots of consequences
      
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8