| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Previously instIsVisible had completely broken the laziness of
lookupInstEnv' since it would examine is_dfun_name to check the name of
the defining module (to know whether it is an interactive module). This
resulted in the visibility check drawing in an interface file
unnecessarily.
|
|
|
|
| |
This allows you to easily move to the result in a well-equipped editor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`okConIdOcc`, which validates that a type or constructor name is valid
for splicing using Template Haskell, has a special case for tuples, but
neglects to look for unboxed tuples, causing some sensible Template Haskell
code involving unboxed tuples to be rejected.
Fixes #12407.
Test Plan: make test TEST=T12407
Reviewers: austin, bgamari, hvr, goldfire
Reviewed By: goldfire
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2410
GHC Trac Issues: #12407
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, Template Haskell reified unboxed tuple types as boxed
tuples with twice the appropriate arity.
Fixes #12403.
Test Plan: make test TEST=T12403
Reviewers: hvr, goldfire, austin, bgamari
Reviewed By: goldfire
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2405
GHC Trac Issues: #12403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Unboxed tuples have `RuntimeRep` arguments which `-XDeriveFunctor` was
mistaking for actual data constructor arguments. As a result, a derived
`Functor` instance for a datatype that contained an unboxed tuple would
generate twice as many arguments as it needed for an unboxed tuple pattern
match or expression. The solution is to simply put `dropRuntimeRepArgs` in the
right place.
Fixes #12399.
Test Plan: ./validate
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: thomie, osa1
Differential Revision: https://phabricator.haskell.org/D2404
GHC Trac Issues: #12399
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The names in the .hp files may contain un-matched opening parentheses,
so escape them.
GHC Trac: #9517
Reviewers: bgamari, austin
Reviewed By: bgamari, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2398
GHC Trac Issues: #9517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is backport of [1] for GHC's copy of Pretty. See Note [Differences
between libraries/pretty and compiler/utils/Pretty.hs].
[1] http://git.haskell.org/packages/pretty.git/commit/bbe9270c5f849a5bb74c9166a5f4202cfb0dba22
https://github.com/haskell/pretty/issues/32
https://github.com/haskell/pretty/pull/35
Reviewers: bgamari, austin
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D2397
GHC Trac Issues: #12227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `-ddump-cmm` put all stages of Cmm processing into one output.
This patch changes its behavior and adds two more options to make
Cmm dumping flexible.
- `-ddump-cmm-from-stg` dumps only initial version of Cmm right after
STG->Cmm codegen
- `-ddump-cmm` dumps the final result of the Cmm pipeline processing
- `-ddump-cmm-verbose` dumps intermediate output of each Cmm pipeline
step
- `-ddump-cmm-proc` and `-ddump-cmm-caf` seems were lost. Now enabled
Test Plan: ./validate
Reviewers: thomie, simonmar, austin, bgamari
Reviewed By: thomie, simonmar
Subscribers: simonpj, thomie
Differential Revision: https://phabricator.haskell.org/D2393
GHC Trac Issues: #11717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: The tests have been included. This change deals with a
relatively minor edge case and should not break unrelated functionality.
Reviewers: thomie, #core_libraries_committee, ekmett, bgamari
Reviewed By: #core_libraries_committee, ekmett, bgamari
Subscribers: bgamari, ekmett
Differential Revision: https://phabricator.haskell.org/D2391
GHC Trac Issues: #11632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's unclear how much of an effect on runtime this will have, but if
nothing else the code generation may be a tad better since the system's
`memcpy` will be used.
Test Plan: Validate
Reviewers: simonmar, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2401
|
|
|
|
|
|
|
|
|
|
|
|
| |
This check is not entirely cheap and will not succeed unless we are
looking for something in the module where built-in syntax lives,
GHC.Types.
Reviewers: simonpj, austin
Subscribers: simonpj, thomie, osa1
Differential Revision: https://phabricator.haskell.org/D2400
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Try it
Reviewers: hvr, simonmar, austin, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1722
GHC Trac Issues: #11094
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Signed-off-by: Baldur Blöndal <baldurpet@gmail.com>
Reviewers: goldfire, RyanGlScott, austin, bgamari, hvr
Reviewed By: RyanGlScott, austin
Subscribers: RyanGlScott, thomie
Differential Revision: https://phabricator.haskell.org/D2268
GHC Trac Issues: #12057
|
|
|
|
|
|
|
|
|
|
|
| |
So that
> :t (id,id,id)
produces
(id,id,id) :: (a3 -> a3, a2 -> a2, a1 -> a1)
instead of
(id,id,id) :: (a2 -> a2, a1 -> a1, a -> a)
Differential Revision: https://phabricator.haskell.org/D2402
|
|
|
|
|
| |
this refactoring commit prepares for fixing #12382, which can now be
implemented soley in tidyTyCoVarBndrs.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the implementation match the description in the paper more
closely: There, a let binding that is not a function has first its body
analised, and then the binding’s RHS. This way, the demand on the bound
variable by the body can be fed into the RHS, yielding more precise
results.
Performance measurements do unfortunately not show significant
improvements or regessions.
Differential Revision: https://phabricator.haskell.org/D2395
|
|
|
|
|
|
|
| |
This changelog is very incomplete, and basically useless. I'm removing
it, because it made it harder to compare this copy of `Pretty.hs` with
the copy in `libraries/pretty` (from which a similar changelog was
deleted some time ago).
|
| |
|
|
|
|
|
| |
Previously it loaded by modulename, which prevented loading files with a
Main module.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would unpack the OccName into a String, then pattern match
against this string. Due to the implementation of `unpackFS`, this
actually unpacks the entire contents, even though we often only need to
look at the first few characters.
Here we take another approach: build a UniqFM with the known built-in
OccNames, allowing us to use `FastString`'s hash-based comparison
instead.
Reviewers: simonpj, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2385
GHC Trac Issues: #12357
|
|
|
|
|
|
| |
Reviewed by: Phyx
Differential Revision: https://phabricator.haskell.org/D2394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was the only user of concatFS and really just wants the `String`
anyways.
Stumbled upon while looking at #12357.
Test Plan: Validate
Reviewers: austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2386
|
|
|
|
| |
GHC Trac: #4012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would form derived OccNames by first decoding the name
being derived from, manipulating it in [Char] form, and then
re-encoding. This is all very wasteful as we essentially always just
want to concatenate. Instead we now take care to form the final name
with only one concatFS.
Test Plan: Validate, examing compiler allocations
Reviewers: simonpj, austin
Reviewed By: simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2387
GHC Trac Issues: #12357
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids decoding the entire string just to look at the first
character.
Test Plan: Validate
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2388
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2389
|
| |
|
|
|
|
|
| |
Instead of unpacking and then repacking we simply concatenate all of the
individual ByteStrings.
|
| |
|
|
|
|
|
|
|
| |
Rationale in the comment.
Also updates submodule array with test output changes.
GHC Trac: #4012
|
|
|
|
| |
Credits goes to SPJ for finding this.
|
|
|
|
|
|
| |
I'm just turning previous commit message into a Note
GHC Trac: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We turn FamInstEnvs into lists in some places which
don't directly affect the ABI. That happens in
family consistency checks and when producing output
for `:info`. Unfortunately that nondeterminism
is nonlocal and it's hard to tell locally what it
affects. Furthermore the envs should be relatively
small, so it should be free to use deterministic
maps here. Testing with nofib and ./validate detected
no difference between UniqFM and UniqDFM.
GHC Trac: #4012
|
|
|
|
|
|
|
|
|
| |
Bit-for-bit reproducible binaries are not a goal for now,
so this is just marking places that could be a problem.
Doing this will allow eltsUFM to be removed and will
leave only nonDetEltsUFM.
GHC Trac: #4012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This file used the old style with type signatures
separated from the code. As far as I understand
the idea was to generate PostScript files from
the source. I think the idea was abandoned and
this more modern style is more common in the
codebase.
Test Plan: it still compiles
Reviewers: austin, simonmar, bgamari
Reviewed By: simonmar, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2383
|
| |
|
|
|
|
|
| |
By making it believe that some deeply nested value is absent when it
really isn't. See #12368.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM 3.8 was released a couple of months ago.
Test Plan: Build and test on x86_64/linux (perf-llvm) and armhf/linux.
Reviewers: austin, hvr, rwbarton, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2382
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This annotates the splice point with 'HsSpliced ref e' where 'e' is the
result of the splice. 'ref' is a reference that the typechecker will fill with
the local type environment.
The finalizer then reads the ref and uses the local type environment, which
causes 'reify' to find local variables when run in the finalizer.
Test Plan: ./validate
Reviewers: simonpj, simonmar, bgamari, austin, goldfire
Reviewed By: goldfire
Subscribers: simonmar, thomie, mboes
Differential Revision: https://phabricator.haskell.org/D2286
GHC Trac Issues: #11832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x86_64-apple-darwin14, is the target for the 64bit simulator.
Ideally, we'd have (i386|armv7|arm64|x64_86)-apple-ios, yet,
many #ifdefs depend on `darwin`, notably libffi. Hence, this only adds
x86_64-apple-darwin14 as a target. This also updates the comment to
add the `-S` flag, and dump the output to stdout; and adjusts the
`datalayout` and `triple` values, as obtained through the method
mentioned in the comment.
Reviewers: hvr, erikd, austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2378
|
|
|
|
|
|
|
|
|
| |
On Darwin versions with clock_gettime, #ifdefs will prevent the
mach-specific time functions from being used in most places, and
the mach time headers won't be included; however, this section
was guarded incorrectly and would still try to use them.
Fixes #12195.
|
|
|
|
|
|
|
|
|
|
| |
varEnvElts can introduce unnecessary nondeterminism
and we can finally remove it, so that no one will use
it by accident. If someone wants to use varEnvElts they
should either use DVarEnv or use nonDetEltsUFM and document
why it doesn't introduce nondeterminism.
GHC Trac: #4012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This localizes the nondeterminism that varEnvElts could
have introduced, so that it's obvious that it's benign.
Test Plan: ./validate
Reviewers: simonpj, austin, bgamari
Subscribers: thomie, simonmar
Differential Revision: https://phabricator.haskell.org/D2390
GHC Trac Issues: #4012
|
|
|
|
|
|
|
| |
We don't care about bit-for-bit reproducibility, so
I'm just documenting this as a possible source.
GHC Trac: #4012
|
| |
|
| |
|