| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: bgamari, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4380
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4368
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By request of @alexbiehl.
CCing @snowleopard and @alpmestan as the same should be done in Hadrian.
Bumps haddock submodule.
Reviewers: alexbiehl
Reviewed By: alexbiehl
Subscribers: rwbarton, thomie, carter, snowleopard, alpmestan, alexbiehl
Differential Revision: https://phabricator.haskell.org/D4365
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Differential Revision: https://phabricator.haskell.org/D4357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that one can produce ill-formed Core by
combining `GeneralizedNewtypeDeriving`, `TypeInType`, and
`TypeFamilies`, as demonstrated in #14728. The root of the problem
is allowing the last parameter of a class to appear in a //kind// of
an associated type family, as our current approach to deriving
associated type family instances simply doesn't work well for that
situation.
Although it might be possible to properly implement this feature
today (see https://ghc.haskell.org/trac/ghc/ticket/14728#comment:3
for a sketch of how this might work), there does not currently exist
a performant implementation of the algorithm needed to accomplish
this. Until such an implementation surfaces, we will make this corner
case of `GeneralizedNewtypeDeriving` an error.
Test Plan: make test TEST="T14728a T14728b"
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14728
Differential Revision: https://phabricator.haskell.org/D4402
|
|
|
|
| |
This change is present in 4.11.0.0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we were skipping over `$tcUnit#` entirely when
wiring in `Typeable` tycons, resulting in #14811. Easily fixed.
Test Plan: make test TEST=T14811
Reviewers: bgamari, dfeuer
Reviewed By: dfeuer
Subscribers: dfeuer, rwbarton, thomie, carter
GHC Trac Issues: #14811
Differential Revision: https://phabricator.haskell.org/D4414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done for consistency. We usually call the package file the same name the
folder has. The move into `utils` is done so that we can move the library into
`libraries/iserv` and the proxy into `utils/iserv-proxy` and then break the
`iserv.cabal` apart. This will make building the cross compiler with TH
simpler, because we can build the library and proxy as separate packages.
Reviewers: bgamari, simonmar, goldfire, erikd
Reviewed By: simonmar
Subscribers: tdammers, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4377
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC didn't inline `eqTypeRep`, presumably because it ended up
being too big. This was unfortunate because it produces a
`Maybe`, which will almost always be scrutinized immediately.
Split `eqTypeRep` into a worker and a tiny wrapper, and mark the
wrapper `INLINABLE`. This change actually seems to reduce Core size,
at least in a small test.
Reviewers: hvr, bgamari, mpickering
Reviewed By: mpickering
Subscribers: mpickering, rwbarton, thomie, carter
GHC Trac Issues: #14790
Differential Revision: https://phabricator.haskell.org/D4405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The make build system appears to be doing a bit of magic in order to supply
the profiled flavours of libHSrts and libCffi, as they're not advertised in
the 'extra-library-flavours' field of rts.cabal.in. This patch explicitly
advertises _p and _thr_p flavours of the RTS library and libCffi, but only
when the RTS is configured with the (newly introduced) 'profiling' flag.
This is necessary for Hadrian, as a branch (soon to be merged) does away with
ghc-cabal and relies just on Cabal to get package information. Without this
patch, Cabal can never inform us that _p and _thr_p flavours should be
built (and registered in the package db) as well, which obviously prevents us
from building a profiled GHC.
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cabal introduces SPDX identifier, and as such we need to change the
BSD3 license name. Also the >= qualifier is no longer prefered.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: alpmestan, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4406
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4393
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, hvr
Reviewed By: bgamari
Subscribers: erikd, hvr, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix missing code example in changelog for 8.4.1
* List 'setEnv' as opposite of 'getEnv'
It seems best to direct users to use 'System.Environment.setEnv'
rather than 'System.Posix.Env.putEnv'. This is due to 'setEnv' being
located in the same module as 'getEnv' and my virtue of working on
Windows platform, whereas 'putEnv' does not have that quality because
it's part of the 'unix' package.
* Reflect in docs the fact that 'readMVar' is not a composition of
'takeMVVar' and 'putMVar' any more
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch includes two changes:
1. Move cost centre collection from `SCCfinal` to `CorePrep`, to be able
to collect cost centres in unfoldings. `CorePrep` drops unfoldings, so
that's the latest stage in the compilation pipeline for this.
After this change `SCCfinal` no longer collects all cost centres, but
it still generates & collects CAF cost centres + updates cost centre
stacks of `StgRhsClosure` and `StgRhsCon`s.
This fixes #5889.
2. Initialize cost centre stack fields of `StgRhs` in `coreToStg`. With
this we no longer need to update cost centre stack fields in
`SCCfinal`, so that module is removed.
Cost centre initialization explained in Note [Cost-centre
initialization plan].
Because with -fcaf-all we need to attach a new cost-centre to each
CAF, `coreTopBindToStg` now returns `CollectedCCs`.
Test Plan: validate
Reviewers: simonpj, bgamari, simonmar
Reviewed By: simonpj, bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #5889
Differential Revision: https://phabricator.haskell.org/D4325
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that `($)` is representation-polymorphic, `($!)` should
surely follow suit.
Reviewers: hvr, bgamari, simonpj
Reviewed By: bgamari, simonpj
Subscribers: simonpj, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4382
|
|
|
|
| |
`NO_PROMOTE_THUNKS` is never defined
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hvr, bgamari, RyanGlScott
Reviewed By: RyanGlScott
Subscribers: RyanGlScott, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When finishing up an implication constraint, it's a bit tricky to
decide which Derived constraints to retain (for error reporting) and
which to discard. I got this wrong in commit
f20cf982f126aea968ed6a482551550ffb6650cf
(Remove wc_insol from WantedConstraints)
The particular problem in Trac #14763 was that we were reporting as an
error a fundep-generated constraint
(ex ~ T)
where 'ex' is an existentially-bound variable in a pattern match.
But this isn't really an error at all.
This patch fixes the problem. Indeed, since I had to understand
this rather tricky code, I took the opportunity to clean it up
and document better. See
isDroppableCt :: Ct -> Bool
and Note [Dropping derived constraints]
I also removed wl_deriv altogether from the WorkList data type. It
was there in the hope of gaining efficiency by not even processing
lots of derived constraints, but it has turned out that most derived
constraints (notably equalities) must be processed anyway; see
Note [Prioritise equalities] in TcSMonad.
The two are coupled because to decide which constraints to put in
wl_deriv I was using another variant of isDroppableCt. Now it's much
simpler -- and perhaps even more efficient too.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: See definition of PRINTF above the change
Reviewers: bgamari, erikd, simonmar, Phyx
Reviewed By: Phyx
Subscribers: Phyx, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4392
|
|
|
|
|
|
| |
This was an oversight from 2671cccde749ed64129097358f81bff43480cdb9
as it wasn't obvious to assume one would go the trouble to manually
construct the pkg-db entries... :-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the redundant superclass expansion
in Trac #14774.
The main change is to fix TcInterac.solveOneFromTheOther, so
that it does not prefer a work-item with a binding if that binding
transitively depends on the inert item we are comparing it with.
Explained in Note [Replacement vs keeping] in TcInert, esp
item (c) of the "Constraints coming from the same level" part.
To make this work I refactored out a new function
TcEvidence.findNeededEvVars, which was previously buried
inside TcSimplify.neededEvVars.
I added quite a few more comments and signposts about superclass
expansion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In prelRules we had:
tx_con_tte :: DynFlags -> AltCon -> AltCon
tx_con_tte _ DEFAULT = DEFAULT
tx_con_tte dflags (DataAlt dc)
| tag == 0 = DEFAULT -- See Note [caseRules for tagToEnum]
| otherwise = LitAlt (mkMachInt dflags (toInteger tag))
The tag==0 case is totally wrong, and led directly to Trac #14768.
See "Beware" in Note [caseRules for tagToEnum] (in the patch).
Easily fixed, though!
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4390
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4386
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original implementation generates a list of SDoc then concatenates
them using `hcat`. For memory optimization, we can transform the given
literal string into escaped string the construct SDoc directly.
This optimization will decreate the memory allocation when there's big
literal strings in haskell code, see Trac #14741.
Signed-off-by: HE, Tao <sighingnow@gmail.com>
Reviewers: bgamari, mpickering, simonpj
Reviewed By: simonpj
Subscribers: simonpj, rwbarton, thomie, carter
GHC Trac Issues: #14741
Differential Revision: https://phabricator.haskell.org/D4384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See comment in Packages for more details.
Fixes #14717.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Test Plan: validate
Reviewers: snoyberg, taylorfausak, bgamari
Reviewed By: snoyberg, taylorfausak, bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14717
Differential Revision: https://phabricator.haskell.org/D4376
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4374
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4373
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: ./validate
Reviewers: goldfire, bgamari, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've explained most of the rationale in a new Note.
I'd happily add a test for this, but the difference is only
visible in run time, allocations remain more or less the same.
FWIW running `generateModules` from #14693 with DEPTH=16, WIDTH=30
finishes in `23s` before, and `11s` after.
Test Plan: ./validate
Reviewers: simonpj, simonmar, bgamari
Reviewed By: simonpj
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14693
Differential Revision: https://phabricator.haskell.org/D4369
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
Differential Revision: https://phabricator.haskell.org/D4379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #14226 noted that the C-- CBE pass frequently fails to
common up semantically identical blocks due to the differences in local
register naming. These patches fixed this by making the pass consider
equality up to alpha-renaming.
However, the new logic failed to consider the possibility that local
register naming *may* matter across multiple blocks. This lead to the
regression #14754. I'll need to do a bit of thinking on a proper
solution to this but in the meantime I'm reverting all four patches.
This reverts commit a27056f9823f8bbe2302f1924b3ab38fd6752e37.
This reverts commit 6f990c54f922beae80362fe62426beededc21290.
This reverts commit 9aa73892e10e90a1799b9277da593e816a827364.
This reverts commit 7920a7d9c53083b234e060a3e72f00b601a46808.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 added a
special caseRule for `dataToTag`, but this transformation completely
broke when `dataToTag` was applied to somewith with a type headed by
a data family, leading to #14680. For now at least, the simplest
solution is to simply not apply this transformation when the type is
headed by a data family.
Test Plan: make test TEST=T14680
Reviewers: simonpj, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14680
Differential Revision: https://phabricator.haskell.org/D4371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC's __sync primitives apparently "usually" imply a full barrier,
meaning they can be used to emulate the more precise C11 atomics albeit
with a loss of efficiency. This restores compatibility with GCC 4.4.
This partially reverts commit 59de290928e6903337f31c1f8107ac8a98ea145d.
Test Plan: Validate on Centos
Reviewers: hvr, simonmar, trommler
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #14244
Differential Revision: https://phabricator.haskell.org/D4364
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4340
|
|
|
|
|
|
|
|
|
|
|
| |
There weas lots of historical cruft to be found here. The `export
SHELLOPTS` breaks on NixOS due to bash syntax in the gcc wrapper script.
Reviewers: hvr
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4347
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4349
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function is called in lots of places, so if it
every fails it's good to know from where it was called.
This is Simon's patch, part of his `wip/T2893` branch.
Test Plan: Validate
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4352
|
|
|
|
|
|
| |
CircleCI seems to suggest that the cost center ordering is wrong in the prof
way. I'm beginning to wonder whether there is some non-determinism here. If only
I know what this test was supposed to be testing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems that most uses of these folds should be strict left folds
(I could only find a single place that benefits from a right fold).
So this removes the existing `setFold`/`mapFold`/`mapFoldWihKey`
replaces them with:
- `setFoldl`/`mapFoldl`/`mapFoldlWithKey` (strict left folds)
- `setFoldr`/`mapFoldr` (for the less common case where a right fold
actually makes sense, e.g., `CmmProcPoint`)
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Test Plan: ./validate
Reviewers: bgamari, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter, kavon
Differential Revision: https://phabricator.haskell.org/D4356
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4361
|