| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were far too noisy to enable by default. In the future we will
hopefully have a more variant of -Wall targetted at these sorts of
diagnostics.
In the interim I've pointed out the existence of these options in the
release
notes in hopes that people will discover them.
Test Plan: Validate
Reviewers: hvr, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit 06d46b1e4507e09eb2a7a04998a92610c8dc6277.
This also has a Haddock submodule update.
Test Plan: validate
Reviewers: simonpj, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a flag -split-sections that does similar things to
-split-objs, but using sections in single object files instead of
relying on the Satanic Splitter and other abominations. This is very
similar to the GCC flags -ffunction-sections and -fdata-sections.
The --gc-sections linker flag, which allows unused sections to actually
be removed, is added to all link commands (if the linker supports it) so
that space savings from having base compiled with sections can be
realized.
Supported both in LLVM and the native code-gen, in theory for all
architectures, but really tested on x86 only.
In the GHC build, a new SplitSections variable enables -split-sections
for relevant parts of the build.
Test Plan: validate with both settings of SplitSections
Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari
Reviewed By: simonmar, thomie, bgamari
Subscribers: hsyl20, erikd, kgardas, thomie
Differential Revision: https://phabricator.haskell.org/D1242
GHC Trac Issues: #8405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We no longer parse old-style GADT syntax but there was some left-over
code for emitting deprecation warnings.
Updates haddock submodule.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1460
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements #10653.
It adds the ability to bundle pattern synonyms with type constructors in
export lists so that users can treat pattern synonyms more like data
constructors.
Updates haddock submodule.
Test Plan: ./validate
Reviewers: goldfire, austin, bgamari
Reviewed By: bgamari
Subscribers: simonpj, gridaphobe, thomie
Differential Revision: https://phabricator.haskell.org/D1258
GHC Trac Issues: #10653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When cross-compiling ghc itself, this prevents:
"dll-split: cannot execute binary file: Exec format error"
Test Plan:
* ./configure --target=arm-linux-gnueabihf
* DYNAMIC_GHC_PROGRAMS=YES
* Stage1Only=NO
Reviewers: rwbarton, bgamari, austin
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1430
|
|
|
|
|
| |
We already used a process-1.4 snapshot with non-bumped version,
so this commit is mostly a `.cabal` file upper-bound relaxation change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment BooleanFormula is defined as
data BooleanFormula a = Var a | And [BooleanFormula a]
| Or [BooleanFormula a]
deriving (Eq, Data, Typeable, Functor, Foldable, Traversable)
An API Annotation can only be attached to an item of the form Located a.
Replace this with a properly Located version, and attach the appropriate
API Annotations to it
Updates haddock submodule.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1384
GHC Trac Issues: #11017
|
|
|
|
|
|
|
|
|
|
| |
This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`
This also needs to relax a few upper bounds on process in some cabal files
(there will be another process submodule update soon, as a major
version bump of process' version is still pending)
|
|
|
|
|
| |
This is needed to prepare for #11026 as these updates
relax the upper bounds on `base` to allow for `base-4.9.0.0`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A utility to check API Annotations was provided in
https://git.haskell.org/ghc.git/commitdiff/43751b2436f370d956d8021b3cdd3
eb77801470b
This commit had poor documentation.
This patch improves the output generated by the utility as well as
supplying better documentation
Test Plan: ./validate
Reviewers: simonpj, austin, bgamari
Reviewed By: austin, bgamari
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1397
GHC Trac Issues: #10917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix building new Sphinx documenation on Windows in msys2 using Awson's patch on #11021.
Install Sphinx using `pacman -S mingw-w64-$(uname -m)-python2-sphinx`
Test Plan: Apply patch and ./validate
Reviewers: thomie, bgamari, austin
Reviewed By: thomie, bgamari
Subscribers: erikd
Differential Revision: https://phabricator.haskell.org/D1408
GHC Trac Issues: #11021
|
|
|
|
|
|
|
|
| |
Starting with directory-1.2.5 there will be a nameclash with
`withCurrentDirectory` and `MIN_VERSION_filepath()` isn't available at
bootstrap-time with the current GHC build-system.
By using explicit import lists we avoid CPP altogether
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second attempt at merging D757.
This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.
However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.
See particularly
* Note [Grand plan for Typeable] in TcTypeable (which is a new module)
* Note [The overall promotion story] in DataCon (clarifies existing
stuff)
The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:
* We need to have enough data types around to *define* a TyCon
* Many of these types are wired-in
Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.
Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969
* T1969: GHC allocates 19% more
* T4801: GHC allocates 13% more
* T5321FD: GHC allocates 13% more
* T9675: GHC allocates 11% more
* T783: GHC allocates 11% more
* T5642: GHC allocates 10% more
I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.
Remaining to do
~~~~~~~~~~~~~~~
* I think that "TyCon" and "Module" are over-generic names to use for
the runtime type representations used in GHC.Typeable. Better might
be
"TrTyCon" and "TrModule". But I have not yet done this
* Add more info the the "TyCon" e.g. source location where it was
defined
* Use the new "Module" type to help with Trac Trac #10068
* It would be possible to generate TyConRepName (ie Typeable
instances) selectively rather than all the time. We'd need to persist
the information in interface files. Lacking a motivating reason I
have
not done this, but it would not be difficult.
Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular
* In TyCon, a type *family* (whether type or data) is repesented by a
FamilyTyCon
* a algebraic data type (including data/newtype instances) is
represented by AlgTyCon This wasn't true before; a data family
was represented as an AlgTyCon. There are some corresponding
changes in IfaceSyn.
* Also get rid of the (unhelpfully named) tyConParent.
* In TyCon define 'Promoted', isomorphic to Maybe, used when things are
optionally promoted; and use it elsewhere in GHC.
* Cleanup handling of knownKeyNames
* Each TyCon, including promoted TyCons, contains its TyConRepName, if
it has one. This is, in effect, the name of its Typeable instance.
Updates haddock submodule
Test Plan: Let Harbormaster validate
Reviewers: austin, hvr, goldfire
Subscribers: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D1404
GHC Trac Issues: #9858
|
|
|
|
|
|
|
|
|
| |
This is needed for #10374 (but doesn't fix it yet).
Also rename DeriveConstants.hs to Main.hs, because the build
system has trouble with Main modules not called Main.hs.
Differential Revision: https://phabricator.haskell.org/D1380
|
| |
|
|
|
|
|
| |
The build system has trouble with Main modules not called Main.hs. This
change allows a hack in utils/runghc/ghc.mk to be removed.
|
|
|
|
|
|
|
|
| |
This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c.
This merge was botched
Also reverts haddock submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.
However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.
See particularly
* Note [Grand plan for Typeable] in TcTypeable (which is a new module)
* Note [The overall promotion story] in DataCon (clarifies existing stuff)
The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:
* We need to have enough data types around to *define* a TyCon
* Many of these types are wired-in
Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.
Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969
* T3294: GHC allocates 110% more (filed #11030 to track this)
* T1969: GHC allocates 30% more
* T4801: GHC allocates 14% more
* T5321FD: GHC allocates 13% more
* T783: GHC allocates 12% more
* T9675: GHC allocates 12% more
* T5642: GHC allocates 10% more
* T9961: GHC allocates 6% more
* T9203: Program allocates 54% less
I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.
Remaining to do
~~~~~~~~~~~~~~~
* I think that "TyCon" and "Module" are over-generic names to use for
the runtime type representations used in GHC.Typeable. Better might be
"TrTyCon" and "TrModule". But I have not yet done this
* Add more info the the "TyCon" e.g. source location where it was
defined
* Use the new "Module" type to help with Trac Trac #10068
* It would be possible to generate TyConRepName (ie Typeable
instances) selectively rather than all the time. We'd need to persist
the information in interface files. Lacking a motivating reason I have
not done this, but it would not be difficult.
Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular
* In TyCon, a type *family* (whether type or data) is repesented by a
FamilyTyCon
* a algebraic data type (including data/newtype instances) is
represented by AlgTyCon This wasn't true before; a data family
was represented as an AlgTyCon. There are some corresponding
changes in IfaceSyn.
* Also get rid of the (unhelpfully named) tyConParent.
* In TyCon define 'Promoted', isomorphic to Maybe, used when things are
optionally promoted; and use it elsewhere in GHC.
* Cleanup handling of knownKeyNames
* Each TyCon, including promoted TyCons, contains its TyConRepName, if
it has one. This is, in effect, the name of its Typeable instance.
Requires update of the haddock submodule.
Differential Revision: https://phabricator.haskell.org/D757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch swaps the order of provided and required constraints in
a pattern signature, so it now goes
pattern P :: req => prov => t1 -> ... tn -> res_ty
See the long discussion in Trac #10928.
I think I have found all the places, but I could have missed something
particularly in comments.
There is a Haddock changes; so a submodule update.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add -fworker-wrapper flag which enables the worker-wrapper transformation. It
is implied by -O.
The expected users of this flag, which includes myself, are GHC API users. In
my Haskell-to-Hardware compiler, which uses the GHC API, I have seen no
benifits of the worker-wrapper transformation. It does however induce longer
compilation times.
Further discussion can be seen here:
https://mail.haskell.org/pipermail/ghc-devs/2015-October/010096.html
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1372
GHC Trac Issues: #11020
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1367
GHC Trac Issues: #10848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is difficult for GHC developers to know if they have broken the API
Annotations.
This patch provides a utility that can be used as a test to show up
errors in the API Annotations.
It is based on the current tests for ghc-api/annotations which can parse
a file using the just-built GHC API, and check that no annotations are
disconnected from the ParsedSource in the output.
In addition, it should be able to dump the annotations to a file, so a
new feature developer can check that all changes to the parser do
provide annotations.
Trac ticket: #10917
Test Plan: ./validate
Reviewers: hvr, thomie, austin, bgamari
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1368
GHC Trac Issues: #10917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements DuplicateRecordFields, the first part of the
OverloadedRecordFields extension, as described at
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
This includes fairly wide-ranging changes in order to allow multiple
records within the same module to use the same field names. Note that
it does *not* allow record selector functions to be used if they are
ambiguous, and it does not have any form of type-based disambiguation
for selectors (but it does for updates). Subsequent parts will make
overloading selectors possible using orthogonal extensions, as
described on the wiki pages. This part touches quite a lot of the
codebase, and requires changes to several GHC API datatypes in order
to distinguish between field labels (which may be overloaded) and
selector function names (which are always unique).
The Haddock submodule has been adapted to compile with the GHC API
changes, but it will need further work to properly support modules
that use the DuplicateRecordFields extension.
Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
will be extended once the other parts are implemented.
Reviewers: goldfire, bgamari, simonpj, austin
Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
goldfire
Differential Revision: https://phabricator.haskell.org/D761
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
| |
Comes with Haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit contains a Cabal submodule update which unifies installed
package IDs and package keys under a single notion, a Component ID.
We update GHC to keep follow this unification. However, this commit
does NOT rename installed package ID to component ID and package key to
unit ID; the plan is to do that in a companion commit.
- Compiler info now has "Requires unified installed package IDs"
- 'exposed' is now expected to contain unit keys, not IPIDs.
- Shadowing is no more. We now just have a very simple strategy
to deal with duplicate unit keys in combined package databases:
if their ABIs are the same, use the latest one; otherwise error.
Package databases maintain the invariant that there can only
be one entry of a unit ID.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari, hvr, goldfire
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1184
GHC Trac Issues: #10714
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
freak out if using a `Data` instance that produces a `Constr` (by means of
`toConstr`) using a function name instead of a data constructor name. While
such `Data` instances are somewhat questionable, they are nevertheless present
in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
aware of their existence.
In order to properly distinguish strings which represent variables (as opposed
to data constructors), it was necessary to move functionality from `Lexeme` (in
`ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
`bin-package-db`).
Reviewed By: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D1313
GHC Trac Issues: #10796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of doing these warnings at MkIface time, we do them
when we create the instances/rules in the typechecker/desugarer.
Emitting warnings for auto-generated instances was a pain
(since the specialization monad doesn't have the capacity
to emit warnings) so instead I just deprecated -fwarn-auto-orphans.
Auto rule orphans are pretty harmless anyway: they don't cause
interface files to be eagerly loaded in.
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/D1297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows preprocessor code calls `runInteractiveProcess` but does
not check if an exception is thrown.
`runInteractiveProcess` calls `CreateProcess` which when given a format
the system loader does not know about
will throw an exception. This is what makes #9399 fail.
Ultimately we should not use any `CreateProcess` based calls but
instead `ShellExecuteEx` as this would allow
us to run applications that the shell knows about instead of just the
loader. More details on #365.
This patch removes `PhaseFailed` and throws `ProgramError` instead.
`PhaseFailed` was largely unneeded since it never gave
very useful information aside from the `errorcode` which was almost
always `1`. `IOErrors` have also been eliminated and `GhcExceptions`
thrown in their place wherever possible.
Updates haddock submodule.
Test Plan:
`./validate` to make sure anything didn't break and
`make TESTS="T365"` to test that an error is now properly thrown
Reviewers: austin, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D1256
GHC Trac Issues: #365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch drops the file level distinction between hs-boot and hsig;
we figure out which one we are compiling based on whether or not there
is a corresponding hs file lying around.
To make the "import A" syntax continue to work for bare hs-boot
files, we also introduce hs-boot merging, which takes an A.hi-boot
and converts it to an A.hi when there is no A.hs file in scope.
This will be generalized in Backpack to merge multiple A.hi files together;
which means we can jettison the "load multiple interface files" functionality.
This works automatically for --make, but for one-shot compilation
we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o
from a local A.hi-boot file; Backpack will extend this mechanism further.
Has Haddock submodule update to deal with change in msHsFilePath behavior.
- This commit drops support for the hsig extension. Can
we support it? It's annoying because the finder code is
written with the assumption that where there's an hs-boot
file, there's always an hs file too. To support hsig, you'd
have to probe two locations. Easier to just not support it.
- #10333 affects us, modifying an hs-boot still doesn't trigger
recomp.
- See compiler/main/Finder.hs: this diff is very skeevy, but
it seems to work.
- This code cunningly doesn't drop hs-boot files from the
"drop hs-boot files" module graph, if they don't have a
corresponding hs file. I have no idea if this actually is useful.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari, spinda
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1098
|
|
|
|
|
|
|
|
| |
Now we use Array to store branches. This makes sense because we often
have to do random access (once inference is done). This also vastly
simplifies the awkward BranchList type.
This fixes #10837 and updates submodule utils/haddock.
|
|
|
|
|
|
|
| |
From the help text:
-i[+|-] sort by identifier string (-i+ gives greatest on top)
Found by David Binderman.
|
|
|
|
| |
This fixes some hpc tests on Windows. Update submodule hpc.
|
|
|
|
|
|
|
|
|
|
| |
Rename StgArrWords to StgArrBytes (see Trac #8552)
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1233
GHC Trac Issues: #8552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in.
See Note [Stage1Only vs stage=1] in mk/config.mk.in.
See Note [No stage2 packages when CrossCompiling or Stage1Only].
Also:
* use stage2 to build mkUserGuidePart, as was probably intended.
Now the following represent the same set of packages:
- packages that we build with ghc-stage2
- packages that depend on the ghc library
Those packages are: haddock, mkUserGuidePart and ghctags.
* don't let utils that don't depend on the ghc library depend on its
package-data.mk file. Instead, let those utils directly depend on
the package-data.mk files of the stage1 packages. Not sure if it
improves anything, but I found it easier to explain what's going on
this way.
(partially) reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There used to be a lot of custom make code to build ghc-pkg with the
stage0 compiler. Commit ac5a314504554ddef0e855ef9e2fcf51e961f4a6
thankfully cleaned this up, by using the build settings from the
ghc-pkg.cabal file.
This commit removes some remains of the old way of installing ghc-pkg
when Stage1Only=YES. Notably, we called both `build-prog` as
`shell-wrapper`. This is surely wrong, because `build-prog` already
calls `shell-wrapper`. It isn't needed to set WANT_INSTALLED_WRAPPER
either; build-prog does that for us.
This prevents the following warnings when Stage1Only=YES:
utils/ghc-pkg/ghc.mk:46: warning:
overriding commands for target `install_utils/ghc-pkg_dist_wrapper'
utils/ghc-pkg/ghc.mk:37: warning:
ignoring old commands for target `install_utils/ghc-pkg_dist_wrapper'
Also add more comments and restructure a bit.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1063
|
|
|
|
|
|
|
| |
Lines like the following are filling up the build logs:
binary-0.7.5.0: cannot find any of
["Data/Binary.hi","Data/Binary.p_hi","Data/Binary.dyn_hi"] (ignoring)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For details see #6018, Phab:D202 and the wiki page:
https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies
This patch also wires-in Maybe data type and updates haddock submodule.
Test Plan: ./validate
Reviewers: simonpj, goldfire, austin, bgamari
Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar,
carter
Differential Revision: https://phabricator.haskell.org/D202
GHC Trac Issues: #6018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch modifies `error`, `undefined`, and `assertError` to use
implicit call-stacks to provide better error messages to users.
There are a few knock-on effects:
- `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
types for `error` and `undefined`.
- `TysPrim.tyVarList` has been replaced with a new function
`TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
subtle bugs when you need tyvars of different kinds. The naive
```
tv1 = head $ tyVarList kind1
tv2 = head $ tyVarList kind2
```
would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
would be applied incorrectly, treating `tv1` and `tv2` as the same
tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
and producing a single tyvar of each kind.
- The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in
ghc-prim.
- The type `GHC.Exception.ErrorCall` has a new constructor
`ErrorCallWithLocation` that takes two `String`s instead of one, the
2nd one being arbitrary metadata about the error (but usually the
call-stack). A bi-directional pattern synonym `ErrorCall` continues to
provide the old API.
Updates Cabal, array, and haddock submodules.
Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari
Reviewed By: simonpj
Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
liyang, bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D861
GHC Trac Issues: #5273
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: simonmar, bgamari, austin
Reviewed By: bgamari, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now identifiers can start with a package key, which is a hash, so they
may also start with a digit. Identifiers always appear at the beginning
of a line, and numbers never appear here, soit's safe to allow
identifiers to start with a digit.
Test Plan: `concprog002` passes under `threaded2_hT` way
Reviewers: austin, bgamari, thomie
Reviewed By: austin, bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D1175
GHC Trac Issues: #10661
|
|
|
|
|
|
|
|
|
|
| |
This will allow fixing #1851 more easily
("make install-strip" should work).
This reverts 57e2a81c589103b50da80a9e378b1a11285bd521:
"On Cygwin, use a Cygwin-style path for /bin/install's destination"
Update submodule haddock and hsc2hs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverses some of the work done in #1405, and goes back to the
assumption that the bootstrap compiler understands GHC-haskell.
In particular:
* use MagicHash instead of _ILIT and _CLIT
* pattern matching on I# if possible, instead of using iUnbox
unnecessarily
* use Int#/Char#/Addr# instead of the following type synonyms:
- type FastInt = Int#
- type FastChar = Char#
- type FastPtr a = Addr#
* inline the following functions:
- iBox = I#
- cBox = C#
- fastChr = chr#
- fastOrd = ord#
- eqFastChar = eqChar#
- shiftLFastInt = uncheckedIShiftL#
- shiftR_FastInt = uncheckedIShiftRL#
- shiftRLFastInt = uncheckedIShiftRL#
* delete the following unused functions:
- minFastInt
- maxFastInt
- uncheckedIShiftRA#
- castFastPtr
- panicDocFastInt and pprPanicFastInt
* rename panicFastInt back to panic#
These functions remain, since they actually do something:
* iUnbox
* bitAndFastInt
* bitOrFastInt
Test Plan: validate
Reviewers: austin, bgamari
Subscribers: rwbarton
Differential Revision: https://phabricator.haskell.org/D1141
GHC Trac Issues: #1405
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updates haddock submodule.
Reviewers: tibbe, goldfire, simonpj, austin, bgamari
Reviewed By: simonpj, bgamari
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1069
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Phab:D907 introduced SourceText for a number of data types, by replacing
FastString with (SourceText,FastString). Since this has an Outputable
instance, no warnings are generated when ppr is called on it, but
unexpected output is generated. See Phab:D1096 for an example of this.
Replace the (SourceText,FastString) tuples with a new data type,
```lang=hs
data StringLiteral = StringLiteral SourceText FastString
```
Update haddock submodule accordingly
Test Plan: ./validate
Reviewers: hvr, austin, rwbarton, trofi, bgamari
Reviewed By: trofi, bgamari
Subscribers: thomie, trofi, rwbarton, mpickering
Differential Revision: https://phabricator.haskell.org/D1101
GHC Trac Issues: #10692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the `StrictData` language extension, which lets the
programmer default to strict data fields in datatype declarations on a
per-module basis.
Specification and motivation can be found at
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
This includes a tricky parser change due to conflicts regarding `~` in
the type level syntax: all ~'s are parsed as strictness annotations (see
`strict_mark` in Parser.y) and then turned into equality constraints at
the appropriate places using `RdrHsSyn.splitTilde`.
Updates haddock submodule.
Test Plan: Validate through Harbormaster.
Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari
Reviewed By: simonpj, tibbe, bgamari
Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering
Differential Revision: https://phabricator.haskell.org/D1033
GHC Trac Issues: #8347
|