| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
GHC Trac Issues: #13564
Differential Revision: https://phabricator.haskell.org/D3516
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This factors out the repetition of (log_action dflags dflags) and will
hopefully allow us to someday better abstract log output.
Test Plan: Validate
Reviewers: austin, hvr, goldfire
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main goal is to easily allow the inline-c project (and
similar projects such as inline-java) to emit C/C++ files to
be compiled and linked with the current module.
Moreover, `addCStub` is removed, since it's quite fragile. Most
notably, the C stubs end up in the file generated by
`CodeOutput.outputForeignStubs`, which is tuned towards
generating a file for stubs coming from `capi` and Haskell-to-C
exports.
Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari
Reviewed By: dfeuer, bgamari
Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes
Differential Revision: https://phabricator.haskell.org/D3280
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch converts the 4 lasting static flags (read from the command
line and unsafely stored in immutable global variables) into dynamic
flags. Most use cases have been converted into reading them from a DynFlags.
In cases for which we don't have easy access to a DynFlags, we read from
'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
It's not perfect (not thread-safe) but it is still better as we can
set/unset these 4 flags before each run when using GHC API.
Updates haddock submodule.
Rebased and finished by: bgamari
Test Plan: validate
Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2839
GHC Trac Issues: #8440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we add support to GHCi for StaticPointers. This process begins by
adding remote GHCi messages for adding entries to the static pointer
table. We then collect binders needing SPT entries after linking and
send the interpreter a message adding entries with the appropriate
fingerprints.
Test Plan: `make test TEST=StaticPtr`
Reviewers: facundominguez, mboes, simonpj, simonmar, goldfire, austin,
hvr, erikd
Reviewed By: simonpj, simonmar
Subscribers: RyanGlScott, simonpj, thomie
Differential Revision: https://phabricator.haskell.org/D2504
GHC Trac Issues: #12356
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new pragma so that users can specify `COMPLETE` sets of
`ConLike`s in order to sate the pattern match checker.
A function which matches on all the patterns in a complete grouping
will not cause the exhaustiveness checker to emit warnings.
```
pattern P :: ()
pattern P = ()
{-# COMPLETE P #-}
foo P = ()
```
This example would previously have caused the checker to warn that
all cases were not matched even though matching on `P` is sufficient to
make `foo` covering. With the addition of the pragma, the compiler
will recognise that matching on `P` alone is enough and not emit
any warnings.
Reviewers: goldfire, gkaracha, alanz, austin, bgamari
Reviewed By: alanz
Subscribers: lelf, nomeata, gkaracha, thomie
Differential Revision: https://phabricator.haskell.org/D2669
GHC Trac Issues: #8779
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Using makeStatic instead of applications of the StaticPtr data
constructor makes possible linting core when unboxing strict
fields.
Test Plan: ./validate
Reviewers: simonpj, goldfire, austin, bgamari, hvr
Reviewed By: simonpj
Subscribers: RyanGlScott, mboes, thomie
Differential Revision: https://phabricator.haskell.org/D2930
GHC Trac Issues: #12622
|
| |
|
|
| |
This reverts commit e5d1ed9c8910839e109da59820ca793642961284.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Kind inference in ghci was interfered when renaming of type splices
introduced the HsSpliced data constructor. This patch has kind
inference skip over it.
Test Plan: ./validate
Reviewers: simonpj, rrnewton, austin, goldfire, bgamari
Reviewed By: goldfire, bgamari
Subscribers: thomie, mboes
Differential Revision: https://phabricator.haskell.org/D2886
GHC Trac Issues: #12985
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin, simonmar
Subscribers: thomie, ezyang
Differential Revision: https://phabricator.haskell.org/D2866
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously BinIface had some dedicated logic for handling tuple names in
the symbol table. As it turns out, this logic was essentially dead code
as it was superceded by the special handling of known-key things. Here
we cull the tuple code-path and use the known-key codepath for all
tuple-ish things.
This had a surprising number of knock-on effects,
* constraint tuple datacons had to be made known-key (previously they
were not)
* IfaceTopBndr was changed from being a synonym of OccName to a
synonym of Name (since we now need to be able to deserialize Names
directly from interface files)
* the change to IfaceTopBndr complicated fingerprinting, since we need
to ensure that we don't go looking for the fingerprint of the thing
we are currently fingerprinting in the fingerprint environment (see
notes in MkIface). Handling this required distinguishing between
binding and non-binding Name occurrences in the Binary serializers.
* the original name cache logic which previously lived in IfaceEnv has
been moved to a new NameCache module
* I ripped tuples and sums out of knownKeyNames since they introduce a
very large number of entries. During interface file deserialization
we use static functions (defined in the new KnownUniques module) to
map from a Unique to a known-key Name (the Unique better correspond
to a known-key name!) When we need to do an original name cache
lookup we rely on the parser implemented in isBuiltInOcc_maybe.
* HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
* Lots of comments were sprinkled about describing the new scheme.
Updates haddock submodule.
Test Plan: Validate
Reviewers: niteria, simonpj, austin, hvr
Reviewed By: simonpj
Subscribers: simonmar, niteria, thomie
Differential Revision: https://phabricator.haskell.org/D2467
GHC Trac Issues: #12532, #12415
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2246
|
| |
|
|
|
| |
This is a tiny refactor, replacing an ad-hoc local function
(TidyPgm.loookup_aux_id) with a solid global one (tidyVarOcc).
|
| |
|
|
|
|
|
|
|
| |
This makes sure that we don't introduce unnecessary
nondeterminism from vectorization.
Also updates dph submodule to reflect the change in types.
GHC Trac: #4012
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We have the FloatOut pass create exported ids for floated StaticPtr
bindings. The simplifier doesn't try to remove those.
This patch also improves on 7fc20b by making a common definition
collectStaticPtrSatArgs to test for StaticPtr binds.
Fixes #12207.
Test Plan: ./validate
Reviewers: simonpj, austin, bgamari, simonmar, goldfire
Reviewed By: simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2366
GHC Trac Issues: #12207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This mostly follows the plan detailed by the discussion
Simon and I had, with one difference: instead of grabbing
the free variables of the trivial expressions to get the
embedded Ids, we just use getIdFromTrivialExpr_maybe to extract
out the Id. If there is no Id, the expression cannot
refer to a function (as there are no literal functions)
and thus we do not need to saturate.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2309
GHC Trac Issues: #12076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We dump it in the interface file, so we need to do it in a
deterministic order. I haven't seen any problems with this
during my testing, but that's probably because it's unused.
Test Plan: ./validate
Reviewers: simonmar, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2313
GHC Trac Issues: #4012
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With this patch closed variables are allowed regardless of whether
they are bound at the top level or not.
The FloatOut pass is always performed. When optimizations are
disabled, only expressions that go to the top level are floated.
Thus, the applications of the StaticPtr data constructor are always
floated.
The CoreTidy pass makes sure the floated applications appear in the
symbol table of object files. It also collects the floated bindings
and inserts them in the static pointer table.
The renamer does not check anymore if free variables appearing in the
static form are top-level. Instead, the typechecker looks at the
tct_closed flag to decide if the free variables are closed.
The linter checks that applications of StaticPtr only occur at the
top of top-level bindings after the FloatOut pass.
The field spInfoName of StaticPtrInfo has been removed. It used to
contain the name of the top-level binding that contains the StaticPtr
application. However, this information is no longer available when the
StaticPtr is constructed, as the binding name is determined now by the
FloatOut pass.
Test Plan: ./validate
Reviewers: goldfire, simonpj, austin, hvr, bgamari
Reviewed By: simonpj
Subscribers: thomie, mpickering, mboes
Differential Revision: https://phabricator.haskell.org/D2104
GHC Trac Issues: #11656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to
`tyCoVarsOfTypeList x`.
Why? If you look at the implementation:
```
tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty
tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty
```
they use the same helper function. The helper function returns a
deterministically ordered list and a set. The only difference
between the two is which part of the result they take. It is redundant
to take the set and then immediately convert it to a list.
This helps with determinism and we eventually want to replace the uses
of `varSetElems` with functions that don't leak the values of uniques.
This change gets rid of some instances that are easy to kill.
I chose not to annotate every place where I got rid of `varSetElems`
with a comment about non-determinism, because once we get rid of
`varSetElems` it will not be possible to do the wrong thing.
Test Plan: ./validate
Reviewers: goldfire, austin, simonmar, bgamari, simonpj
Reviewed By: simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2115
GHC Trac Issues: #4012
|
| |
|
|
|
| |
to be consistent with the other uses of nop vs. top in Demand.hs. Also,
stop prettyprinting top strictness signatures in Core dumps.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds timings and allocation figures to the compiler's output when
run with `-v2` in an effort to ease performance analysis.
Todo:
* Documentation
* Where else should we add these?
* Perhaps we should remove some of the now-arguably-redundant
`showPass` occurrences where they are
* Must we force more?
* Perhaps we should place this behind a `-ftimings` instead of `-v2`
Test Plan: `ghc -v2 Test.hs`, look at the output
Reviewers: hvr, goldfire, simonmar, austin
Reviewed By: simonmar
Subscribers: angerman, michalt, niteria, ezyang, thomie
Differential Revision: https://phabricator.haskell.org/D1959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both gcc and clang tell which warning flag a reported warning can be
controlled with, this patch makes ghc do the same. More generally, this
allows for annotated compiler output, where an optional annotation is
displayed in brackets after the severity.
This also adds a new flag `-f(no-)show-warning-groups` to control
whether to show which warning-group (such as `-Wall` or `-Wcompat`)
a warning belongs to. This flag is on by default.
This implements #10752
Reviewed By: quchen, bgamari, hvr
Differential Revision: https://phabricator.haskell.org/D1943
|
| | |
|
| |
|
|
| |
...following a question from Conal
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
| |
|
|
|
|
| |
Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`,
which allows to simplify some definitions to exploit the superclass
relationship. This a first refactoring to that end.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
such that the explicit definitions for `return` and `(>>)` match the
MRP-style default-implementation, i.e.
return = pure
and
(>>) = (*>)
This way, e.g. all `return = pure` definitions can easily be grepped and
removed in GHC 8.1;
Test Plan: Harbormaster
Reviewers: goldfire, alanz, bgamari, quchen, austin
Reviewed By: quchen, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1312
|
| |
|
|
|
|
| |
Comes with Haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: simonpj, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1319
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverses some of the work done in Trac #1405, and assumes GHC is
smart enough to do its own unboxing of booleans now.
I would like to do some more performance measurements, but the code
changes can be reviewed already.
Test Plan:
With a perf build:
./inplace/bin/ghc-stage2 nofib/spectral/simple/Main.hs -fforce-recomp
+RTS -t --machine-readable
before:
```
[("bytes allocated", "1300744864")
,("num_GCs", "302")
,("average_bytes_used", "8811118")
,("max_bytes_used", "24477464")
,("num_byte_usage_samples", "9")
,("peak_megabytes_allocated", "64")
,("init_cpu_seconds", "0.001")
,("init_wall_seconds", "0.001")
,("mutator_cpu_seconds", "2.833")
,("mutator_wall_seconds", "4.283")
,("GC_cpu_seconds", "0.960")
,("GC_wall_seconds", "0.961")
]
```
after:
```
[("bytes allocated", "1301088064")
,("num_GCs", "310")
,("average_bytes_used", "8820253")
,("max_bytes_used", "24539904")
,("num_byte_usage_samples", "9")
,("peak_megabytes_allocated", "64")
,("init_cpu_seconds", "0.001")
,("init_wall_seconds", "0.001")
,("mutator_cpu_seconds", "2.876")
,("mutator_wall_seconds", "4.474")
,("GC_cpu_seconds", "0.965")
,("GC_wall_seconds", "0.979")
]
```
CPU time seems to be up a bit, but I'm not sure. Unfortunately CPU time
measurements are rather noisy.
Reviewers: austin, bgamari, rwbarton
Subscribers: nomeata
Differential Revision: https://phabricator.haskell.org/D1143
GHC Trac Issues: #1405
|
| |
|
|
|
| |
This allows PprCore to use these functions. It will soon do so to enable
CoreLint to output size annotations on top-level bindings.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that.
Reviewers: austin, jstolarek, hvr, goldfire
Reviewed By: austin, jstolarek
Subscribers: thomie, goldfire
Differential Revision: https://phabricator.haskell.org/D621
GHC Trac Issues: #9986
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [Disgusting computation of CafRefs] in TidyPgm.
Also affects CoreUtils.rhsIsStatic.
The real solution here is to compute CAF and arity information
from the STG-program, and feed it back to tidied program for
the interface file and later GHCi clients. A battle for another
day.
But at least this commit reduces the number of gratuitous CAFs, and
hence SRT entries. And kills off a batch of ASSERT failures.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two related bugs here
Trac #9426
We must increment the ic_mod_index field of the InteractiveContext
if we have new instances, because we maek DFunIds that should be
distinct from previous ones. Previously we were only incrementing
when defining new user-visible Ids.
The main change is in HscTypes.extendInteractiveContext, which now
alwyas bumps the ic_mod_index. I also added a specialised
extendInteractiveContextWithIds for the case where we are *only*
adding new user-visible Ids.
Trac #9424
In HscMain.hscDeclsWithLocations we were failing to use the
*tidied* ClsInsts; but the un-tidied ones are LocalIds which
causes a later ASSERT error.
On the way I realised that, to behave consistently, the tcg_insts
and tcg_fam_insts field of TcGblEnv should really only contain
instances from the current GHCi command, not all the ones to date.
That in turn meant I had to move the code for deleting replacement
instances from addLocalInst, addLocalFamInst to
HscTypes.extendInteractiveContext
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There should be no bindings in this module for a GlobalId;
except after CoreTidy, when top-level bindings are globalised.
To check for this, I had to make the CoreToDo pass part of the
environment that Core Lint caries. But CoreToDo is defined in
CoreMonad, which (before this patch) called CoreLint.
So I had to do quite a bit of refactoring, moving some
lint-invoking code into CoreLint itself. Crucially, I also
more tcLookupImported_maybe, importDecl, and checkwiredInTyCon
from TcIface (which use CoreLint) to LoadIface (which doesn't).
This is probably better structure anyway.
So most of this patch is refactoring. The actual check for
GlobalIds is in CoreLint.lintAndScopeId
|
|
|
Signed-off-by: Austin Seipp <austin@well-typed.com>
|