1. 21 Jan, 2018 1 commit
    • Takenobu Tani's avatar
      Implement underscores in numeric literals (NumericUnderscores extension) · 4a13c5b1
      Takenobu Tani authored
      Implement the proposal of underscores in numeric literals.
      Underscores in numeric literals are simply ignored.
      
      The specification of the feature is available here:
      https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/000
      9-numeric-underscores.rst
      
      For a discussion of the various choices:
      https://github.com/ghc-proposals/ghc-proposals/pull/76
      
      Implementation detail:
      
      * Added dynamic flag
        * `NumericUnderscores` extension flag is added for this feature.
      
      * Alex "Regular expression macros" in Lexer.x
        * Add `@numspc` (numeric spacer) macro to represent multiple
          underscores.
        * Modify `@decimal`, `@decimal`, `@binary`, `@octal`, `@hexadecimal`,
          `@exponent`, and `@bin_exponent` macros to include `@numspc`.
      
      * Alex "Rules" in Lexer.x
        * To be simpler, we have only the definitions with underscores.
          And then we have a separate function (`tok_integral` and `tok_frac`)
          that validates the literals.
      
      * Validation functions in Lexer.x
        * `tok_integral` and `tok_frac` functions validate
          whether contain underscores or not.
          If `NumericUnderscores` extensions are not enabled,
          check that there are no underscores.
        * `tok_frac` function is created by merging `strtoken` and
          `init_strtoken`.
        * `init_strtoken` is deleted. Because it is no longer used.
      
      * Remove underscores from target literal string
        * `parseUnsignedInteger`, `readRational__`, and `readHexRational} use
          the customized `span'` function to remove underscores.
      
      * Added Testcase
        * testcase for NumericUnderscores enabled.
            NumericUnderscores0.hs and NumericUnderscores1.hs
        * testcase for NumericUnderscores disabled.
            NoNumericUnderscores0.hs and NoNumericUnderscores1.hs
        * testcase to invalid pattern for NumericUnderscores enabled.
            NumericUnderscoresFail0.hs and NumericUnderscoresFail1.hs
      
      Test Plan: `validate` including the above testcase
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: carter, rwbarton, thomie
      
      GHC Trac Issues: #14473
      
      Differential Revision: https://phabricator.haskell.org/D4235
      4a13c5b1
  2. 21 Dec, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14588 by checking for more bang patterns · 9caf40e9
      Ryan Scott authored
      Summary:
      Commit 37299536
      inadvertently removed a check in the parser which rejected
      let-bindings with bang patterns, leading to #14588. This fixes it by
      creating a `hintBangPat` function to perform this check, and
      sprinkling it in the right places.
      
      Test Plan: make test TEST=T14588
      
      Reviewers: bgamari, alanz, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #14588
      
      Differential Revision: https://phabricator.haskell.org/D4270
      9caf40e9
  3. 25 Oct, 2017 1 commit
  4. 28 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Do not discard insolubles in implications · 452755de
      Simon Peyton Jones authored
      Trac #14000 showed up two errors
      
      * In TcRnTypes.dropInsolubles we dropped all implications, which
        might contain the very insolubles we wanted to keep.  This was
        an outright error, and is why the out-of-scope error was actually
        lost altogether in Trac #14000
      
      * In TcSimplify.simplifyInfer, if there are definite (insoluble)
        errors, it's better to suppress the following ambiguity test,
        because the type may be bogus anyway.  See TcSimplify
        Note [Quantification with errors].  This fix seems a bit clunky,
        but it'll do for now.
      452755de
  5. 11 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13948 by being pickier about when to suggest DataKinds · ba46e63f
      Ryan Scott authored
      Commit 343cb32d (#13568) made GHC a bit
      too cavalier in suggesting when data constructors are in scope (and
      suggesting the use of `DataKinds`). This tones down the suggestions so
      that `DataKinds` is only suggested if a data constructor of that name is
      actually in scope (previously, it would always suggest, even if it was
      out of scope).
      
      Fixes #13948.
      
      Test Plan: ./validate
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13948
      
      Differential Revision: https://phabricator.haskell.org/D3719
      ba46e63f
  6. 15 May, 2017 1 commit
  7. 11 May, 2017 1 commit
    • mrkgnao's avatar
      Fix incorrect ambiguity error on identically-named data constructors · 1381c142
      mrkgnao authored
      Given multiple in-scope constructors with the same name, say `A`, and a
      function of type `A -> Int`, say, the compiler reports both a "type `A`
      is not in scope" and (incorrectly) an ambiguity error. The latter
      shouldn't be there if `DataKinds` isn't enabled.
      
      This issue was recommended to me by @mpickering as a suitable first
      task, and the fix was also outlined in the original Trac ticket. It
      involved a simple reordering of the steps taken in `lookup_demoted` in
      `RnEnv.hs`. The fix is to make the `DataKinds` check happen earlier,
      ensuring that the ambiguity check doesn't happen at all if we know the
      constructors couldn't have been promoted.
      Signed-off-by: mrkgnao's avatarSoham Chowdhury <chow.soham@gmail.com>
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13568
      
      Differential Revision: https://phabricator.haskell.org/D3547
      1381c142
  8. 29 Mar, 2017 1 commit
  9. 13 Mar, 2017 1 commit
  10. 10 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      Improve error messages for skolems · 48d1866e
      Simon Peyton Jones authored
      In error messages like this
          • Couldn't match type ‘c’ with ‘f0 (a -> b)’
            ‘c’ is a rigid type variable bound by
              the type signature for:
                f :: ((a -> b) -> b) -> forall c. c -> a
      
      we need to take case both to actually show that 'forall c',
      and to make sure that its name lines with the 'c' in the
      error message.
      
      This has been shaky for some time, and this commit puts it on solid
      ground.  See TcRnTypes: Note [SigSkol SkolemInfo]
      
      The main changes are
      
      * SigSkol gets an extra field that records the way in which the
        type signature was skolemised.
      
      * The type in SigSkol is now the /un/-skolemised version
      
      * pprSkolemInfo uses the info to make the tidy type line up
        nicely
      
      Lots of error message wibbles!
      48d1866e
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      
      All this led to Trac #13371 and Trac #13393.
      
      This commit tidies it all up:
      
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      
      In doing all this I also made UniqDFM behave a little more nicely:
      
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      
      I may not have associated all of them with the correct commit.
      7e96526a
  11. 06 Mar, 2017 1 commit
  12. 03 Mar, 2017 3 commits
  13. 09 Feb, 2017 1 commit
  14. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. Add a TcLevel to SkolemTvs. This will be useful generally
      
          - it's a fast way to see if the type
            variable escapes when floating (not used yet)
      
          - it provides a good consistency check when updating a
            unification variable (TcMType.writeMetaTyVarRef, the
            level_check_ok check)
      
         I originally had another reason (related to the flirting
         in (2), but I left it in because it seems like a step in
         the right direction.
      
      5. Reduce and simplify the plethora of uExpType,
         tcSubType and related functions in TcUnify.  It was
         such an opaque mess and it's still not great, but it's
         better.
      
      6. Simplify the uo_expected field of TypeEqOrigin.  Richard
         had generatlised it to a ExpType, but it was almost always
         a Check type.  Now it's back to being a plain TcType which
         is much, much easier.
      
      7. Improve error messages by refraining from skolemisation when
         it's clear that there's an error: see
         TcUnify Note [Don't skolemise unnecessarily]
      
      8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
         so I added it
      
      9. Kill off tcs_used_tcvs.  Its purpose is to track the
         givens used by wanted constraints.  For dictionaries etc
         we do that via the free vars of the /bindings/ in the
         implication constraint ic_binds.  But for coercions we
         just do update-in-place in the type, rather than
         generating a binding.  So we need something analogous to
         bindings, to track what coercions we have added.
      
         That was the purpose of tcs_used_tcvs.  But it only
         worked for a /single/ iteration, whereas we may have
         multiple iterations of solving an implication.  Look
         at (the old) 'setImplicationStatus'.  If the constraint
         is unsolved, it just drops the used_tvs on the floor.
         If it becomes solved next time round, we'll pick up
         coercions used in that round, but ignore ones used in
         the first round.
      
         There was an outright bug.  Result = (potentialy) bogus
         unused-constraint errors.  Constructing a case where this
         actually happens seems quite trick so I did not do so.
      
         Solution: expand EvBindsVar to include the (free vars of
         the) coercions, so that the coercions are tracked in
         essentially the same way as the bindings.
      
         This turned out to be much simpler.  Less code, more
         correct.
      
      10. Make the ic_binds field in an implication have type
            ic_binds :: EvBindsVar
          instead of (as previously)
             ic_binds :: Maybe EvBindsVar
          This is notably simpler, and faster to use -- less
          testing of the Maybe.  But in the occaional situation
          where we don't have anywhere to put the bindings, the
          belt-and-braces error check is lost.  So I put it back
          as an ASSERT in 'setImplicationStatus' (see the use of
          'termEvidenceAllowed')
      
      All these changes led to quite bit of error message wibbling
      3f5673f3
  15. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765
  16. 20 Jun, 2016 1 commit
  17. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
      
        - tyConBinders :: [TyConBinder]
      
      The new data types look like this:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
      
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
      
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      
      Some smaller points
      ~~~~~~~~~~~~~~~~~~~
      * Nice new functions
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
      e368f326
  18. 19 May, 2016 1 commit
  19. 18 May, 2016 1 commit
    • niteria's avatar
      Kill varSetElems in tidyFreeTyCoVars · 6282bc31
      niteria authored
      I haven't observed this to have an effect on nondeterminism,
      but tidyOccName appears to modify the TidyOccEnv in a
      way dependent on the order of inputs.
      It's easy enough to change it to be deterministic to be on the
      safe side.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2238
      
      GHC Trac Issues: #4012
      6282bc31
  20. 26 Apr, 2016 1 commit
    • niteria's avatar
      Kill varSetElemsWellScoped in quantifyTyVars · c9bcaf31
      niteria authored
      varSetElemsWellScoped introduces unnecessary non-determinism in
      inferred type signatures.
      Removing this instance required changing the representation of
      TcDepVars to use deterministic sets.
      This is the last occurence of varSetElemsWellScoped, allowing me to
      finally remove it.
      
      Test Plan:
      ./validate
      I will update the expected outputs when commiting, some reordering
      of type variables in types is expected.
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2135
      
      GHC Trac Issues: #4012
      c9bcaf31
  21. 25 Feb, 2016 1 commit
  22. 23 Feb, 2016 3 commits
  23. 19 Feb, 2016 1 commit
    • thomie's avatar
      Modifier letter in middle of identifier is ok · d738e664
      thomie authored
      Refactoring only. Cleanup some loose ends from #10196.
      
      Initially the idea was to only allow modifier letters at the end of
      identifiers. Since we later decided to allow modifier letters also in
      the middle of identifiers (because not doing so would not fix the
      regression completely), the names `suffix` and `okIdSuffixChar` don't
      seem appropriate anymore.
      
      Remove TODO. Move test from should_fail to should_compile.
      d738e664
  24. 17 Feb, 2016 1 commit
  25. 27 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  26. 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
  27. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  28. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
      
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
      
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
      
        HsExplicitFlag disappears altogether.
      
      * Other simplifications
      
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
      
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
      
           - PatSynSig records a LHsSigType rather than the decomposed
             pieces
      
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      
      * Renamed LHsTyVarBndrs to LHsQTyVars
      
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      
      I also did a bunch of loosely-related changes:
      
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
      
            TcCoercionN/TcCoercionR
      
            mkWpCastN/mkWpCastN
      
        All just type synonyms but jolly useful.
      
      * I record-ised ForeignImport and ForeignExport
      
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      
      Updates haddock submodule.
      1e041b73
  29. 24 Nov, 2015 1 commit
    • elaforge's avatar
      Rearrange error msgs and add section markers (Trac #11014). · c05fddde
      elaforge authored
      This puts the "Relevant bindings" section at the end.
      
      It uses a TcErrors.Report Monoid to divide messages by importance and
      then mappends them together.  This is not the most efficient way since
      there are various intermediate Reports and list appends, but it probably
      doesn't matter since error messages shouldn't get that large, and are
      usually prepended.  In practice, everything is `important` except
      `relevantBindings`, which is `supplementary`.
      
      ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc,
      which has important, context, and suppelementary fields.  Each of those
      three sections is marked with a bullet character, '•' on unicode
      terminals and '*' on ascii terminals.  Since this breaks tons of tests,
      I also modified testlib.normalise_errmsg to strip out '•'s.
      
      --- Additional notes:
      
      To avoid prepending * to an empty doc, I needed to filter empty docs.
      This seemed less error-prone than trying to modify everyone who produces
      SDoc to instead produce Maybe SDoc.  So I added `Outputable.isEmpty`.
      Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise
      I think I'd need another Empty case for SDoc, and then it couldn't be a
      newtype any more.
      
      ErrMsg's errMsgShortString is only used by the Show instance, which is
      in turn only used by Show HscTypes.SourceError, which is in turn only
      needed for the Exception instance.  So it's probably possible to get rid
      of errMsgShortString, but that would a be an unrelated cleanup.
      
      Fixes #11014.
      
      Test Plan: see above
      
      Reviewers: austin, simonpj, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: simonpj, nomeata, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1427
      
      GHC Trac Issues: #11014
      c05fddde
  30. 22 Oct, 2015 1 commit
  31. 08 Oct, 2015 1 commit
    • thomie's avatar
      Parser: revert some error messages to what they were before 7.10 · e2b579e8
      thomie authored
      Among doing other things, Phab:D201 (bc2289e1)
      tried to improve the error messages thrown by the parser. For example a missing
      else clause now prints "parse error in if statement: else clause empty" instead
      of "parse error (possibly incorrect indentation or mismatched brackets)".
      
      Some error messages got much worse however (see tests), and the result seems to
      be a net negative. Although not entirely satisfactory, this commits therefore
      reverts those parser changes.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D1309
      
      GHC Trac Issues: #10498
      e2b579e8
  32. 03 Oct, 2015 2 commits
    • Tamar Christina's avatar
      Fix broken validation Build 6564 and accepting a few other test results · c4d7df04
      Tamar Christina authored
      Test Plan: ./validate
      
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1304
      c4d7df04
    • Tamar Christina's avatar
      Prevent GHC from silently dying when preprocessor is not found · b6f76b9a
      Tamar Christina authored
      The Windows preprocessor code calls `runInteractiveProcess` but does
      not check if an exception is thrown.
      `runInteractiveProcess` calls `CreateProcess` which when given a format
      the system loader does not know about
      will throw an exception. This is what makes #9399 fail.
      
      Ultimately we should not use any `CreateProcess` based calls but
      instead `ShellExecuteEx` as  this would allow
      us to run applications that the shell knows about instead of just the
      loader. More details on #365.
      
      This patch removes `PhaseFailed` and throws `ProgramError` instead.
      `PhaseFailed` was largely unneeded since it never gave
      very useful information aside from the `errorcode` which was almost
      always `1`. `IOErrors` have also been eliminated and `GhcExceptions`
      thrown in their place wherever possible.
      
      Updates haddock submodule.
      
      Test Plan:
      `./validate` to make sure anything didn't break and
      `make TESTS="T365"` to test that an error is now properly thrown
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1256
      
      GHC Trac Issues: #365
      b6f76b9a
  33. 30 Jul, 2015 1 commit
    • JohnWiegley's avatar
      Improve error message for newtypes and deriving clauses · 4f80ec0e
      JohnWiegley authored
      Summary:
      Change the error message generated when a deriving clause related to a newtype
      fails to always suggested trying GeneralizedNewtypeDeriving, even in
      situations where it may not work. Fixes #9600.
      
      Test Plan: testsuite/deriving/should_fail/9600.hs
      
      Reviewers: austin, bgamari, simonpj
      
      Rebased-by: bgamari
      
      Reviewed By: simonpj
      
      Subscribers: bgamari, hvr, simonmar, carter
      
      Differential Revision: https://phabricator.haskell.org/D216
      
      GHC Trac Issues: #9600
      4f80ec0e
  34. 14 Jul, 2015 1 commit