Roland Senn authored 6 years ago and Krzysztof Gogolewski committed 6 years ago

Summary: After a parse error in OPTIONS_GHC issue an error message instead of a compiler panic.

Test Plan: make test TEST=T15053

Reviewers: Phyx, thomie, bgamari, monoidal, osa1

Reviewed By: Phyx, monoidal, osa1

Subscribers: tdammers, osa1, rwbarton, carter

GHC Trac Issues: #15053

Differential Revision: https://phabricator.haskell.org/D5093

Ben Sklaroff authored 6 years ago and Ben Gamari committed 6 years ago

When parsing a nested comment or nested doc comment in the lexer, if we
see a line starting with '#' we attempt to parse a #line pragma. This
fixes how ghc handles output of the C preproccesor (-cpp flag) when the
original source has C comments or pragmas inside haskell comments.

Updates haddock submodule.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #314

Differential Revision: https://phabricator.haskell.org/D4934

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Reviewers: Phyx

Reviewed By: Phyx

Subscribers: Phyx, rwbarton, thomie, carter

GHC Trac Issues: #15053

Differential Revision: https://phabricator.haskell.org/D4883

Summary:
Implement the "Embrace Type :: Type" GHC proposal,
.../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst

GHC 8.0 included a major change to GHC's type system: the Type :: Type
axiom. Though casual users were protected from this by hiding its
features behind the -XTypeInType extension, all programs written in GHC
8+ have the axiom behind the scenes. In order to preserve backward
compatibility, various legacy features were left unchanged. For example,
with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
Now these restrictions are lifted and -XTypeInType becomes a redundant
flag that will be eventually deprecated.

* Incorporate the features currently in -XTypeInType into the
  -XPolyKinds and -XDataKinds extensions.
* Introduce a new extension -XStarIsType to control how to parse * in
  code and whether to print it in error messages.

Test Plan: Validate

Reviewers: goldfire, hvr, bgamari, alanz, simonpj

Reviewed By: goldfire, simonpj

Subscribers: rwbarton, thomie, mpickering, carter

GHC Trac Issues: #15195

Differential Revision: https://phabricator.haskell.org/D4748

Currently, the primitive `(~#)`, `(~R#)`, and `(~P#)` type
constructors are wired in to be exported from `GHC.Prim`. This has
some unfortunate consequences, however. It turns out that `(~#)` is
actually a legal infix identifier, so users can make use of unboxed
equalities in strange ways in user code (see #15209). The other two,
`(~R#)` and `(~P#)`, can't be used in source code, but they can be
observed with GHCi's `:browse` command, which is somewhat unnerving.

The fix for both of these problems is simple: just don't wire them
to be exported from `GHC.Prim`.

Test Plan: make test TEST="T12023 T15209"

Reviewers: bgamari, dfeuer

Reviewed By: bgamari, dfeuer

Subscribers: rwbarton, thomie, carter, dfeuer

GHC Trac Issues: #12023, #15209

Differential Revision: https://phabricator.haskell.org/D4801

For empty character literal, the `''`, report error message properly
rather than just throw a "parser error" with wrong error location.

Test Plan: make test TEST="T13450 T13450TH"

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie, mpickering, carter

GHC Trac Issues: #13450

Differential Revision: https://phabricator.haskell.org/D4594

Given this program:

    main = do
      f $ do
        a <- return 3
          c <- do
          return 5

GHC previously gave this error message:

    Main.hs:2:7: error:
        Parse error in pattern: do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |       ^^...

What happened is GHC considered the whole `f $ do a <- return 3 c` as a
pattern. When parsed as an expression it becomes an infix application of
`($)`, and GHC checks left and right hand sides before checking if `($)`
is a valid infix constructor name, and shows the first error it got.

If instead we first check if the infix op is valid in pattern context,
the error message becomes much clearer:

    Main.hs:2:3: error:
        Parse error in pattern: f $ do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |   ^^^^^^...

This may not entirely fix #11188 but I think it's an improvement.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11188

Differential Revision: https://phabricator.haskell.org/D4497

This patch is preparatory for the main fix for Trac #13324

Here, we simplify rnLHsInstType so that it does not try
to figure out the class name.  This turns out to have a good
(rather than bad) effect on error messages, and it prepares
the way for the main event.

Plus, less code!

Empty GADTs data declarations can't be identified in type checker. This
patch adds additional checks in parser and raise a parse error when
encounter empty GADTs declarations but extension `GADTs` is not enabled.

Only empty declarations are checked in parser to avoid affecting
existing
error messages related to missing GADTs extension.

This patch should fix issue 8258.

Signed-off-by: HE, Tao <sighingnow@gmail.com>

Test Plan: make test TEST="T8258 T8258NoGADTs"

Reviewers: bgamari, mpickering, alanz, RyanGlScott

Reviewed By: bgamari, RyanGlScott

Subscribers: adamse, RyanGlScott, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #8258

Differential Revision: https://phabricator.haskell.org/D4350

Fixes #14740.

Test Plan: make test TEST="14740"

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14740

Differential Revision: https://phabricator.haskell.org/D4359

takano-akio authored 7 years ago and Ben Gamari committed 7 years ago

This patch implements the BlockArguments extension, as proposed at
https://github.com/ghc-proposals/ghc-proposals/pull/90. It also
fixes #10855 as a side-effect.

This patch adds a large number of shift-reduce conflicts to the parser.
All of them concern the ambiguity as to where constructs like `if` and
`let` end. Fortunately they are resolved correctly by preferring shift.

The patch is based on @gibiansky's ArgumentDo implementation (D1219).

Test Plan: ./validate

Reviewers: goldfire, bgamari, alanz, mpickering

Reviewed By: bgamari, mpickering

Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #10843, #10855

Differential Revision: https://phabricator.haskell.org/D4260

Takenobu Tani authored 7 years ago and Ben Gamari committed 7 years ago

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

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

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.

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

Dave Laing authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: validate

Reviewers: austin, bgamari, simonmar, mpickering

Reviewed By: mpickering

Subscribers: mpickering, rwbarton, thomie

GHC Trac Issues: #12610

Differential Revision: https://phabricator.haskell.org/D3584

mrkgnao authored 7 years ago and Ben Gamari committed 7 years ago

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: Soham 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

ruperthorlick authored 7 years ago and Ben Gamari committed 7 years ago

Changes in a few different places to catch several different
types of error related to RecursiveDo

Signed-off-by: Rupert Horlick <ruperthorlick@gmail.com>

Test Plan: Three test cases, with further tests in comments

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D3271

Rufflewind authored 8 years ago and Ben Gamari committed 8 years ago

This corrects the line numbers for literate code after a shebang.
Fixes #13414.

Test Plan: validate

Reviewers: austin, bgamari, trofi

Reviewed By: bgamari, trofi

Subscribers: trofi, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3333

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!

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.

ruperthorlick authored 8 years ago and Ben Gamari committed 8 years ago

Signed-off-by: Rupert Horlick <ruperthorlick@gmail.com>

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3286

It's unclear why this didn't show up in my initial local validation. Oh
well.

ruperthorlick authored 8 years ago and Ben Gamari committed 8 years ago

Added a check for whether RankNTypes is enabled
and changed error message accordingly

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D3262

ruperthorlick authored 8 years ago and Ben Gamari committed 8 years ago

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D3261

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

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

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.

A minor parser issue, allowing a mal-formed data constructor
through.

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

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

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.

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.