1. 08 Mar, 2018 2 commits
2. 02 Mar, 2018 1 commit
3. 18 Feb, 2018 1 commit
• Add valid refinement substitution suggestions for typed holes · 918c0b39
Matthías Páll Gissurarson authored and Ben Gamari committed
```This adds valid refinement substitution suggestions for typed holes and
documentation thereof.

Inspired by Agda's refinement facilities, this extends the typed holes
feature to be able to search for valid refinement substitutions, which
are substitutions that have one or more holes in them.

When the flag `-frefinement-level-substitutions=n` where `n > 0` is
passed, we also look for valid refinement substitutions, i.e.
substitutions that are valid, but adds more holes. Consider the
following:

f :: [Integer] -> Integer
f = _

Here the valid substitutions suggested will be (with the new
`-funclutter-valid-substitutions` flag for less verbosity set):

```
Valid substitutions include
f :: [Integer] -> Integer
product :: forall (t :: * -> *).
Foldable t => forall a. Num a => t a -> a
sum :: forall (t :: * -> *).
Foldable t => forall a. Num a => t a -> a
maximum :: forall (t :: * -> *).
Foldable t => forall a. Ord a => t a -> a
minimum :: forall (t :: * -> *).
Foldable t => forall a. Ord a => t a -> a
head :: forall a. [a] -> a
(Some substitutions suppressed; use -fmax-valid-substitutions=N or
-fno-max-valid-substitutions)
```

When the `-frefinement-level-substitutions=1` flag is given, we
additionally compute and report valid refinement substitutions:

```
Valid refinement substitutions include
foldl1 _ :: forall (t :: * -> *).
Foldable t => forall a. (a -> a -> a) -> t a -> a
foldr1 _ :: forall (t :: * -> *).
Foldable t => forall a. (a -> a -> a) -> t a -> a
head _ :: forall a. [a] -> a
last _ :: forall a. [a] -> a
error _ :: forall (a :: TYPE r).
GHC.Stack.Types.HasCallStack => [Char] -> a
errorWithoutStackTrace _ :: forall (a :: TYPE r). [Char] -> a
(Some refinement substitutions suppressed; use
-fmax-refinement-substitutions=N or -fno-max-refinement-substitutions)
```

Which are substitutions with holes in them. This allows e.g. beginners
to discover the fold functions and similar.

We find these refinement suggestions by considering substitutions that
don't fit the type of the hole, but ones that would fit if given an
additional argument. We do this by creating a new type variable with
newOpenFlexiTyVarTy (e.g. `t_a1/m[tau:1]`), and then considering
substitutions of the type `t_a1/m[tau:1] -> v` where `v` is the type of
the hole. Since the simplifier is free to unify this new type variable
with any type (and it is cloned before each check to avoid
side-effects), we can now discover any identifiers that would fit if
given another identifier of a suitable type. This is then generalized
so that we can consider any number of additional arguments by setting
the `-frefinement-level-substitutions` flag to any number, and then
considering substitutions like e.g. `foldl _ _` with two additional
arguments.

This can e.g. help beginners discover the `fold` functions.
This could also help more advanced users figure out which morphisms
they can use when arrow chasing.
Then you could write `m = _ . m2 . m3` where `m2` and `m3` are some
morphisms, and not only get exact fits, but also help in finding
morphisms that might get you a little bit closer to where you want to
go in the diagram.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

4. 05 Feb, 2018 1 commit
• Improve unboxed sum documentation · d987f71a
David Feuer authored and David Feuer committed
```* Clarify the representation of sums without fields.
* Try to improve language, clarity, and examples.

Fixes #14752

Reviewers: osa1, bgamari

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14752

5. 01 Feb, 2018 1 commit
• Implement BlockArguments (#10843) · be84823b
takano-akio authored and Ben Gamari committed
```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

6. 26 Jan, 2018 1 commit
• Sort valid substitutions for typed holes by "relevance" · cbdea959
Matthías Páll Gissurarson authored and Ben Gamari committed
```This is an initial attempt at tackling the issue of how to order the
suggestions provided by the valid substitutions checker, by sorting
them by creating a graph of how they subsume each other. We'd like to
order them in such a manner that the most "relevant" suggestions are
displayed first, so that the suggestion that the user might be looking
for is displayed before more far-fetched suggestions (and thus also
displayed when they'd otherwise be cut-off by the
`-fmax-valid-substitutions` limit). The previous ordering was based on
the order in which the elements appear in the list of imports, which I
believe is less correlated with relevance than this ordering.

A drawback of this approach is that, since we now want to sort the
elements, we can no longer "bail out early" when we've hit the
`-fmax-valid-substitutions` limit.

Reviewers: bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, rwbarton, thomie, carter

7. 21 Jan, 2018 2 commits
• Implement underscores in numeric literals (NumericUnderscores extension) · 4a13c5b1
Takenobu Tani authored and Ben Gamari committed
```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:

* `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
the customized `span'` function to remove underscores.

* 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

• tentative improvement to callstack docs · 5edb18a9
Alp Mestanogullari authored and Ben Gamari committed
```This is an attempt at clarifying the docs for HasCallStack in both the
user guide and libraries/base/GHC/Stack/Types.hs. The example used right
now is built around an hypothetical 'error' function that doesn't itself
print call stacks, and the fact that this doesn't hold makes it all
confusing, see #14635.

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14635

8. 03 Jan, 2018 2 commits
9. 02 Jan, 2018 1 commit
10. 21 Dec, 2017 1 commit
• Document ScopedTypeVariables' interaction with nested foralls · b6304f8f
Ryan Scott authored
```Summary:
This documents the status quo with regards to how
`ScopedTypeVariables` brings into scope type variables that are
quantified by nested `forall`s (that is to say, it doesn't). This
takes the prose in
and enshrines it into the users' guide.

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14288

11. 19 Dec, 2017 1 commit
12. 18 Dec, 2017 1 commit
• Fix scoping of pattern-synonym existentials · f1fe5b4a
Simon Peyton Jones authored
```This patch fixes Trac #14998, where we eventually decided that
the existential type variables of the signature of a pattern
synonym should not scope over the pattern synonym.

See Note [Pattern synonym existentials do not scope] in TcPatSyn.```
13. 11 Dec, 2017 1 commit
14. 15 Nov, 2017 1 commit
• StaticPointers: Clarify documentation · 6dfe9828
Facundo Domínguez authored and Ben Gamari committed
``` * Document requirement to use the same binaries.

Test Plan: ./validate

Reviewers: bgamari, mboes, hvr

Reviewed By: bgamari, mboes

Subscribers: rwbarton, thomie

15. 06 Nov, 2017 1 commit
• Typo in glasgow_exts.rst · 2ded5368
Douglas Wilson authored and Ben Gamari committed
```Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

16. 03 Nov, 2017 1 commit
17. 02 Nov, 2017 2 commits
• Implement the basics of hex floating point literals · b0b80e90
Iavor S. Diatchki authored and Ben Gamari committed
```Implement hexadecmial floating point literals.

The digits of the mantissa are hexadecimal.
The exponent is written in base 10, and the base for the exponentiation is 2.
Hexadecimal literals look a lot like ordinary decimal literals, except that
they use hexadecmial digits, and the exponent is written using `p` rather than `e`.

The specification of the feature is available here:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0004-hexFloats.rst

For a discussion of the various choices:
https://github.com/ghc-proposals/ghc-proposals/pull/37

Reviewers: mpickering, goldfire, austin, bgamari, hvr

Reviewed By: bgamari

Subscribers: mpickering, thomie

• Implement the EmptyDataDeriving proposal · 1317ba62
Ryan Scott authored and Ben Gamari committed
```This implements the `EmptyDataDeriving` proposal put forth in
https://github.com/ghc-proposals/ghc-proposals/blob/dbf51608/proposals/0006-deriving-empty.rst.
This has two major changes:

* The introduction of an `EmptyDataDeriving` extension, which
permits directly deriving `Eq`, `Ord`, `Read`, and `Show` instances
for empty data types.
* An overhaul in the code that is emitted in derived instances for
empty data types. To see an overview of the changes brought forth,
refer to the changes to the 8.4.1 release notes.

Test Plan: ./validate

Reviewers: bgamari, dfeuer, austin, hvr, goldfire

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #7401, #10577, #13117

18. 25 Oct, 2017 1 commit
• Make language extensions their own category in the documentation · 61f1b46e
Joachim Breitner authored
```I.e. instead of

.. ghc-flag:: -XUnboxedTuples
:shortdesc: Enable the use of unboxed tuple syntax.
:type: dynamic
:reverse: -XNoUnboxedTuples
:category:

one simply writes

.. extension:: UnboxedTuples
:shortdesc: Enable the use of unboxed tuple syntax.

This allows language extensions to be referenced as

If :extension:`UnboxedTuples` is enabled, then...

This directive still creates the entries for the `-XUnboxedTuples` flag,
so in particular,

Set :ghc-flag:`-XUnboxedTuples` if you have to.

still works, and lists of flags in general (e.g. for the manpage)
include these.

I also removed lots of links from the shortdesc of the extensions, when
this link simply points to the section where the extension is defined.

I removed the list of `-X` flags from the flag reference table, but added a
table of extension under “10.1. Language options”

Lots of text in the manual now refers to “extension `Foo`” rather than
“flag `-XFoo`”.

I consider `-XFoo` a historic artifact that stems from when language
extensions were really just flags. These days, the use of `-XFoo` is
(IMHO) deprecated: You should be using `LANGUAGE Foo`, or maybe the
appropriate field in a `.cabal` file. See 9278994a which did this change

19. 20 Oct, 2017 1 commit
20. 19 Oct, 2017 1 commit
21. 17 Oct, 2017 1 commit
• Improve user’s guide around deriving · 317aa966
Joachim Breitner authored
```In particular:
* add an intro to “10.6. Extensions to the “deriving” mechanism” giving
an overview,
* make the various sections on `-XDerivingFoo` subsections of
“10.6.3. Deriving instances of extra classes (Data, etc.)”
* Move the reference anchors for the various `DerivingFoo` extensions
to a more appropriate spot.
* Add subsection “10.6.6.1. Default deriving strategy” to the
deriving section (#14357)```
22. 15 Oct, 2017 1 commit
• Remove section about ApplicativeDo & existentials (#13875) · 4a677f76
Simon Marlow authored
```Summary:
This section is irrelevant now that strict pattern matches don't get
the ApplicativeDo treatment.

Test Plan:
```
make html FAST=YES
```

Reviewers: bgamari, austin, erikd

Subscribers: rwbarton, thomie

GHC Trac Issues: #13875

23. 13 Oct, 2017 1 commit
• Delete obsolete docs on GADT interacton with TypeApplications · 2be55b85
Ryan Scott authored
```Even since ef26182e, this section of
the users' guide is wrong, as there are no longer special rules for
the order of type variables in GADT constructors' type signatures
vis-à-vis visible type application. As a result, this section can
simply be deleted, as there is no longer anything interesting to say
24. 26 Sep, 2017 1 commit
25. 25 Sep, 2017 1 commit
• Document how GHC disambiguates between multiple COMPLETE sets · 0e60cc18
Ryan Scott authored
```Summary:
Up until now, the knowledge of how GHC chooses which
`COMPLETE` set to use in the presence of multiple applicable
`COMPLETE` sets for a single data type constructor was only
documented in the GHC wiki. But this really should be advertised to
anyone who uses `COMPLETE` pragmas heavily, so per SPJ's advice in
this wisdom to the GHC users' guide.

Reviewers: austin, bgamari

Subscribers: mpickering, rwbarton, thomie

GHC Trac Issues: #14253

26. 05 Sep, 2017 1 commit
• Implicitly bind kind variables in type family instance RHSes when it's sensible · 0829821a
Ryan Scott authored
```Summary:
Before, there was a discrepancy in how GHC renamed type synonyms as
opposed to type family instances. That is, GHC would accept definitions like
this one:

type T = (Nothing :: Maybe a)
```

However, it would not accept a very similar type family instance:

type family   T :: Maybe a
type instance T = (Nothing :: Maybe a)
```

The primary goal of this patch is to bring the renaming of type family
instances up to par with that of type synonyms, causing the latter definition
to be accepted, and fixing #14131.

In particular, we now allow kind variables on the right-hand sides of type
(and data) family instances to be //implicitly// bound by LHS type (or kind)
patterns (as opposed to type variables, which must always be explicitly
bound by LHS type patterns only). As a consequence, this allows programs
reported in #7938 and #9574 to typecheck, whereas before they would
have been rejected.

Implementation-wise, there isn't much trickery involved in making this happen.
We simply need to bind additional kind variables from the RHS of a type family
in the right place (in particular, see `RnSource.rnFamInstEqn`, which has
undergone a minor facelift).

While doing this has the upside of fixing #14131, it also made it easier to
trigger #13985, so I decided to fix that while I was in town. This was
accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

GHC Trac Issues: #13985, #14131

27. 02 Sep, 2017 1 commit
• Disallow bang/lazy patterns in the RHSes of implicitly bidirectional patsyns · 5dd6b13c
Ryan Scott authored
```Summary:
GHC was allowing implicitly bidirectional pattern synonyms with bang
patterns and irrefutable patterns in the RHS, like so:

pattern StrictJust a = Just !a
```

This has multiple problems:

1. `Just !a` isn't a valid expression, so it feels strange to allow it in an
implicitly bidirectional pattern synonym.
2. `StrictJust` doesn't provide the strictness properties one would expect
from a strict constructor. (One could imagine a design where the
`StrictJust` builder infers a bang pattern for its pattern variable, but
accomplishing this inference in a way that accounts for all possible
patterns on the RHS, including other pattern synonyms, is somewhat
awkward, so we do not pursue this design.)

We nip these issues in the bud by simply disallowing bang/irrefutable patterns
on the RHS.

Test Plan: make test TEST="T14112 unidir"

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

GHC Trac Issues: #14112

28. 01 Sep, 2017 1 commit
29. 26 Aug, 2017 1 commit
30. 19 Aug, 2017 1 commit
• users_guide: Convert mkUserGuidePart generation to a Sphinx extension · cf8ab1ce
patrickdoc authored and Ben Gamari committed
```This removes all dependencies the users guide had on `mkUserGuidePart`.
The generation of the flag reference table and the various pieces of the
man page is now entirely contained within the Spinx extension
`flags.py`. You can see the man page generation on the orphan page

The extension works by collecting all of the meta-data attached to the
`ghc-flag` directives and then formatting and displaying it at
`flag-print` directives. There is a single printing directive that can
be customized with two options, what format to display (table, list, or
block of flags) and an optional category to limit the output to
(verbosity, warnings, codegen, etc.).

New display formats can be added by creating a function
`generate_flag_xxx` (where `xxx` is a description of the format) which
takes a list of flags and a category and returns a new `xxx`. Then just
add a reference in the dispatch table `handlers`. That display can now
be run by passing `:type: xxx` to the `flag-print` directive.

`flags.py` contains two maps of settings that can be adjusted. The first
is a canonical list of flag categories, and the second sets default
categories for files.

The only functionality that Sphinx could not replace was the
`what_glasgow_exts_does.gen.rst` file. `mkUserGuidePart` actually just
reads the list of flags from `compiler/main/DynFlags.hs` which Sphinx
cannot do. As the flag is deprecated, I added the list as a static file
which can be updated manually.

data from `mkUserGuidePart` to generate the reference table.

Fixes #11654 and, incidentally, #12155.

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #11654, #12155

31. 17 Aug, 2017 3 commits
32. 15 Aug, 2017 1 commit
33. 07 Aug, 2017 1 commit
34. 27 Jul, 2017 1 commit
• Fix #12369 by being more flexible with data insts · 42392383
Richard Eisenberg authored
```Previously, a data family's kind had to end in `Type`,
and data instances had to list all the type patterns for the
family. However, both of these restrictions were unnecessary:

- A data family's kind can usefully end in a kind variable `k`.
See examples on #12369.

- A data instance need not list all patterns, much like how a
GADT-style data declaration need not list all type parameters,
when a kind signature is in place. This is useful, for example,
here:

data family Sing (a :: k)
data instance Sing :: Bool -> Type where ...

This patch also improved a few error messages, as some error
plumbing had to be moved around.

See new Note [Arity of data families] in FamInstEnv for more
info.

test case: indexed-types/should_compile/T12369```