| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #17880 demonstrates that `DeriveFunctor`-generated code is
surprisingly fragile when rank-_n_ types are involved. The culprit is
that `$fmap` (the algorithm used to generate `fmap` implementations)
was too keen on applying arguments with rank-_n_ types to lambdas,
which fail to typecheck more often than not.
In this patch, I change `$fmap` (both the specification and the
implementation) to produce code that avoids creating as many lambdas,
avoiding problems when rank-_n_ field types arise.
See the comments titled "Functor instances" in `TcGenFunctor` for a
more detailed description. Not only does this fix #17880, but it also
ensures that the code that `DeriveFunctor` generates will continue
to work after simplified subsumption is implemented (see #17775).
What is truly amazing is that #17880 is actually a regression
(introduced in GHC 7.6.3) caused by commit
49ca2a37bef18aa57235ff1dbbf1cc0434979b1e, the fix #7436. Prior to
that commit, the version of `$fmap` that was used was almost
identical to the one used in this patch! Why did that commit change
`$fmap` then? It was to avoid severe performance issues that would
arise for recursive `fmap` implementations, such as in the example
below:
```hs
data List a = Nil | Cons a (List a) deriving Functor
-- ===>
instance Functor List where
fmap f Nil = Nil
fmap f (Cons x xs) = Cons (f x) (fmap (\y -> f y) xs)
```
The fact that `\y -> f y` was eta expanded caused significant
performance overheads. Commit
49ca2a37bef18aa57235ff1dbbf1cc0434979b1e fixed this performance
issue, but it went too far. As a result, this patch partially
reverts 49ca2a37bef18aa57235ff1dbbf1cc0434979b1e.
To ensure that the performance issues pre-#7436 do not resurface,
I have taken some precautionary measures:
* I have added a special case to `$fmap` for situations where the
last type variable in an application of some type occurs directly.
If this special case fires, we avoid creating a lambda expression.
This ensures that we generate
`fmap f (Cons x xs) = Cons (f x) (fmap f xs)` in the derived
`Functor List` instance above. For more details, see
`Note [Avoid unnecessary eta expansion in derived fmap implementations]`
in `TcGenFunctor`.
* I have added a `T7436b` test case to ensure that the performance
of this derived `Functor List`-style code does not regress.
When implementing this, I discovered that `$replace`, the algorithm
which generates implementations of `(<$)`, has a special case that is
very similar to the `$fmap` special case described above. `$replace`
marked this special case with a custom `Replacer` data type, which
was a bit overkill. In order to use the same machinery for both
`Functor` methods, I ripped out `Replacer` and instead implemented
a simple way to detect the special case. See the updated commentary
in `Note [Deriving <$]` for more details.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this refactoring:
* DerivInfo for data family instances was returned from tcTyAndClassDecls
* DerivInfo for data declarations was generated with mkDerivInfos and added at a
later stage of the pipeline in tcInstDeclsDeriv
After this refactoring:
* DerivInfo for both data family instances and data declarations is returned from
tcTyAndClassDecls in a single list.
This uniform treatment results in a more convenient arrangement to fix #16731.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for built-in Natural literals in Core.
- Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
constructor with a LitNumType field
- Support built-in Natural literals
- Add desugar warning for negative literals
- Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
reasons
This patch introduces only a few rules for Natural literals (compared
to Integer's rules). Factorization of the built-in rules for numeric
literals will be done in another patch as this one is already big to
review.
Test Plan:
validate
test build with integer-simple
Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar
Reviewed By: bgamari
Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
thomie
GHC Trac Issues: #14170, #14465
Differential Revision: https://phabricator.haskell.org/D4212
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the default definition of `<$` for derived `Functor`
instance is very bad for recursive data types. Derive
the definition instead.
Fixes #13218
Reviewers: austin, bgamari, RyanGlScott
Reviewed By: RyanGlScott
Subscribers: RyanGlScott, thomie
Differential Revision: https://phabricator.haskell.org/D3072
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add prettyprinter tests, which take a file, parse it, pretty print it,
re-parse the pretty printed version and then compare the original and
new ASTs (ignoring locations)
Updates haddock submodule to match the AST changes.
There are three issues outstanding
1. Extra parens around a context are not reproduced. This will require an
AST change and will be done in a separate patch.
2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
to prevent noise in the output.
I am not sure what the desired behaviour in this case is, so have left
it as before. Test Ppr047 is marked as expected fail for this.
3. Apart from in a context, the ParsedSource AST keeps all the parens from
the original source. Something is happening in the renamer to remove the
parens around visible type application, causing T12530 to fail, as the
dumped splice decl is after the renamer.
This needs to be fixed by keeping the parens, but I do not know where they
are being removed. I have amended the test to pass, by removing the parens
in the expected output.
Test Plan: ./validate
Reviewers: goldfire, mpickering, simonpj, bgamari, austin
Reviewed By: simonpj, bgamari
Subscribers: simonpj, goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D2752
GHC Trac Issues: #3384
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This implements the ability to derive associated type family instances
for newtypes automatically using `GeneralizedNewtypeDeriving`. Refer to the
users' guide additions for how this works; I essentially follow the pattern
laid out in https://ghc.haskell.org/trac/ghc/ticket/8165#comment:18.
Fixes #2721 and #8165.
Test Plan: ./validate
Reviewers: simonpj, goldfire, austin, bgamari
Reviewed By: simonpj
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D2636
GHC Trac Issues: #2721, #8165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an instance declaration when you don't specify the code for a
method, GHC fills in from the default binding in the class.
The type of the default method can legitmiately be ambiguous ---
see Note [Default methods in instances] in TcInstDcls --- so
typechecking it can be tricky.
Trac #12220 showed that although we were dealing with that ambiguity
for /vanilla/ default methods, we were not doing so for /generic/
default methods. Moreover we were dealing with it clumsily, by
generating post-typechecked code.
This patch fixes the bug AND deletes code! We now use the same code
path for both vanilla and generic default methods; and generate
/pre-typechecked/ code in both cases. The key trick is that we can use
Visible Type Application to deal with the ambiguity, which wasn't
possible before. Hooray.
There is a small hit to performance in compiler/perf/T1969 which
consists of nothing BUT instance declarations with several default
methods to fill, which we now have to typecheck. The actual hit is
from 724 -> 756 or 4% in that extreme example. Real world programs
have vastly fewer instance decls.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, derived implementations of `to`/`from` in `Generic`
instances were wastefully putting extra `M1`s in every case, which led
to an O(n) increase in the number of coercions, resulting in a slowdown
during the typechecker phase.
This factors out the common `M1` in every case of a `to`/`from`
definition so that the typechecker has far fewer coercions to deal with.
For a datatype with 300 constructors, this change has been observed to
save almost 3 seconds of compilation time.
This is one step towards coming up with a solution for #5642.
Test Plan: ./validate
Reviewers: hvr, austin, simonpj, bgamari
Reviewed By: bgamari
Subscribers: basvandijk, carter, thomie, osa1
Differential Revision: https://phabricator.haskell.org/D2304
GHC Trac Issues: #5642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This augments `MetaSel` with a `Bang` field, which gives generic
programmers access to the following information about each field
selector:
* `SourceUnpackedness`: whether a field was marked `{-# NOUNPACK #-}`,
`{-# UNPACK #-}`, or not
* `SourceStrictness`: whether a field was given a strictness (`!`) or
laziness (`~`) annotation
* `DecidedStrictness`: what strictness GHC infers for a field during
compilation, which may be influenced by optimization levels,
`-XStrictData`, `-funbox-strict-fields`, etc.
Unlike in Phab:D1603, generics does not grant a programmer the ability
to "splice" in metadata, so there is no issue including
`DecidedStrictness` with `Bang` (whereas in Template Haskell, it had to
be split off).
One consequence of this is that `MetaNoSel` had to be removed, since it
became redundant. The `NoSelector` empty data type was also removed for
similar reasons.
Fixes #10716.
Test Plan: ./validate
Reviewers: dreixel, goldfire, kosmikus, austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1646
GHC Trac Issues: #10716
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate.
Reviewers: simonpj, goldfire, hvr, dreixel, kosmikus, austin, bgamari
Reviewed By: kosmikus, austin, bgamari
Subscribers: RyanGlScott, Fuuzetsu, bgamari, thomie, carter, dreixel
Differential Revision: https://phabricator.haskell.org/D493
GHC Trac Issues: #9766
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
DeriveGeneric generates some data types (for data type constructors and for
selectors of those constructors) and instances for those types. This patch
changes name generation for these new types to make it working with data types
with same names imported from different modules and with data types with same
names imported from same modules(using module imports).
Bonus content:
- Some refactoring in `TcGenGenerics.metaTyConsToDerivStuff` to remove some
redundant partial function applications and to remove a duplicated function.
- Remove some unused names from `OccName`. (those were used for an old
implementation of `DeriveGeneric`)
Reviewers: kosmikus, simonpj, dreixel, ezyang, bgamari, austin
Reviewed By: bgamari, austin
Subscribers: ezyang, thomie
Differential Revision: https://phabricator.haskell.org/D1081
GHC Trac Issues: #10487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Added packageName to GHC.Generics.Datatype class definition
Reviewers: hvr, dreixel, austin
Reviewed By: dreixel, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D631
GHC Trac Issues: #10030
|
| | |
|
| | |
|
| |
|
|
| |
Most of these tests were written by Nicolas Frisby.
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
In particular, we are testing the output of deriving
Generic instances.
|
