| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Differential Revision: https://phabricator.haskell.org/D1785
|
|
|
|
|
|
|
| |
This adds a new variant of AbsBinds that is used solely for bindings
with a type signature. This allows for a simpler desugaring that
does not produce the bogus output that tripped up Core Lint in
ticket #11405. Should make other desugarings simpler, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously injective type families were part of TypeFamilies.
Now they are in a separate language extension.
Test Plan: ./validate
Reviewers: austin, bgamari, goldfire
Reviewed By: bgamari
Subscribers: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D1750
GHC Trac Issues: #11381
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hvr, thomie, austin
Reviewed By: austin
Subscribers: duncan
Differential Revision: https://phabricator.haskell.org/D1741
GHC Trac Issues: #8176, #4437
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A set of changes to enable local ghc env files to be useful for tools
like cabal. Ultimately it will allow cabal to maintain a ghc env file so
that users can simple run ghc or ghci in a project directory and get the
expected environment of the project.
Change the name of .ghc.environment files to include the platform and
ghc version, e.g. .ghc.environment.x86_64-linux-7.6.3, since their
content is version specific. Strictly speaking this is not backwards
compatible, but we think this feature is not widely used yet.
"Look up" for a local env file, like the behaviour of git/darcs etc. So
you can be anywhere within a project and get the expected environment.
Don't look for local env files when -hide-all-packages is given.
Extend the syntax of env files to allow specifying package dbs too.
Test Plan:
Currently completely untested. Compiles, that is all.
Sorry, have to disappear for the hols.
Reviewers: hvr, ezyang, austin, bgamari
Reviewed By: ezyang, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1668
GHC Trac Issues: #11268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since #11316 indicates that having flag `-Wtoo-many-guards`
enabled by default causes issues, the simplest thing is to
remove it. This patch removes it from the default list, it
updates the docs and removes the suppression flags for
`T783` and `types/OptCoercion.hs`
Test Plan: validate
Reviewers: bgamari, austin, goldfire
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1737
GHC Trac Issues: #11316
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and
GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP
compatibility CPP-mess for good!
Reviewers: austin, goldfire, bgamari
Subscribers: goldfire, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduction of two new flags, for more precise control over the new
pattern match checker's behaviour when reasoning about guards. This is
supposed to address #11195 (and maybe more performance bugs related to
the NP-Hardness of coverage checking).
Expected behaviour:
* When `-ffull-guard-reasoning` is on, run the new pattern match
checker in its full power
* When `-ffull-guard-reasoning` is off (the default), for every
match, check a metric to see whether pattern match checking for it
has high probability of being non performant (at the the moment we
check whether the number of guards is over 20 but I would like to
use a more precise measure in the future). If the probability is
high:
- Oversimplify the guards (less expressive but more performant)
and run the checker, and
- Issue a warning about the simplification that happened.
A new flag `-Wtoo-many-guards/-Wno-too-many-guards` suppresses the
warning about the simplification (useful when combined with -Werror).
Test Plan: validate
Reviewers: goldfire, austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D1676
GHC Trac Issues: #11195
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-working of the typechecker algorithm is based on
the paper "Visible type application", by Richard Eisenberg,
Stephanie Weirich, and Hamidhasan Ahmed, to be published at
ESOP'16.
This patch introduces -XTypeApplications, which allows users
to say, for example `id @Int`, which has type `Int -> Int`. See
the changes to the user manual for details.
This patch addresses tickets #10619, #5296, #10589.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The basic idea is that we have a new set of "exposed modules"
which are /only/ used for plugins, i.e. -fplugin Foo and
--frontend Foo. You can interact with this namespace
using the flags -plugin-package-id and -plugin-package.
By default, this namespace contains all modules in the
user namespace (as before), but you can toggle that using
-hide-all-plugin-packages.
There is one nasty hack: GhcMake respects -fplugin in
GHC_OPTIONS to make local plugins work correctly. It also
bails out of you have an import of a module which doesn't
exist locally or in the package database. The upshot is
that we need to be sure to check in the plugin modules
too, so we don't give a spurious failure when a plugin
is in the plugin namespace but not the main namespace.
A better way to fix this would be to distinguish between
plugin and normal dependencies in ModSummary.
I cheated a little and tweaked a few existing plugins
tests to exercise the new code paths.
TODO: Documentation
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: bgamari, austin, simonpj, duncan
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1661
GHC Trac Issues: #11244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, all package flags (-package, -trust-package,
-ignore-package) were bundled up into a single packageFlags
field in DynFlags, under a single type. This commit separates
them based on what they do.
This is a nice improvement, because it means that Packages can
then be refactored so that a number of functions are "tighter":
- We know longer have to partition PackageFlags into
the ignore flag and other flags; ignore flags are just
put into their own field.
- Trust flags modify the package database, but exposed
flags do not (they modify the visibility map); now
applyPackageFlag and applyTrustFlag have tighter signatures
which reflect this.
This patch was motivated by the need to have a separate visibility
map for plugin packages, which will be in a companion patch.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari, duncan
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Breakpoints become SCCs, so we have detailed call-stack info for
interpreted code. Currently this only works when GHC is compiled with
-prof, but D1562 (Remote GHCi) removes this constraint so that in the
future call stacks will be available without building your own GHCi.
How can you get a stack trace?
* programmatically: GHC.Stack.currentCallStack
* I've added an experimental :where command that shows the stack when
stopped at a breakpoint
* `error` attaches a call stack automatically, although since calls to
`error` are often lifted out to the top level, this is less useful
than it might be (ImplicitParams still works though).
* Later we might attach call stacks to all exceptions
Other related changes in this diff:
* I reduced the number of places that get ticks attached for
breakpoints. In particular there was a breakpoint around the whole
declaration, which was often redundant because it bound no variables.
This reduces clutter in the stack traces and speeds up compilation.
* I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few
other small cleanups
Test Plan: validate
Reviewers: ezyang, bgamari, austin, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1595
GHC Trac Issues: #11047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of duplicating its logic. Refactoring only.
For reference, `defaultWays` looks like this:
defaultWays :: Settings -> [Way]
defaultWays settings = if pc_DYNAMIC_BY_DEFAULT (sPlatformConstants settings)
then [WayDyn]
else []
Reviewed by: bgamari
Differential Revision: https://phabricator.haskell.org/D1675
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: thomie, austin, bgamari
Reviewed By: thomie, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1625
GHC Trac Issues: #10662
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
(Apologies for the size of this patch, I couldn't make a smaller one
that was validate-clean and also made sense independently)
(Some of this code is derived from GHCJS.)
This commit adds support for running interpreted code (for GHCi and
TemplateHaskell) in a separate process. The functionality is
experimental, so for now it is off by default and enabled by the flag
-fexternal-interpreter.
Reaosns we want this:
* compiling Template Haskell code with -prof does not require
building the code without -prof first
* when GHC itself is profiled, it can interpret unprofiled code, and
the same applies to dynamic linking. We would no longer need to
force -dynamic-too with TemplateHaskell, and we can load ordinary
objects into a dynamically-linked GHCi (and vice versa).
* An unprofiled GHCi can load and run profiled code, which means it
can use the stack-trace functionality provided by profiling without
taking the performance hit on the compiler that profiling would
entail.
Amongst other things; see
https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
Notes on the implementation are in Note [Remote GHCi] in the new
module compiler/ghci/GHCi.hs. It probably needs more documenting,
feel free to suggest things I could elaborate on.
Things that are not currently implemented for -fexternal-interpreter:
* The GHCi debugger
* :set prog, :set args in GHCi
* `recover` in Template Haskell
* Redirecting stdin/stdout for the external process
These are all doable, I just wanted to get to a working validate-clean
patch first.
I also haven't done any benchmarking yet. I expect there to be slight hit
to link times for byte code and some penalty due to having to
serialize/deserialize TH syntax, but I don't expect it to be a serious
problem. There's also lots of low-hanging fruit in the byte code
generator/linker that we could exploit to speed things up.
Test Plan:
* validate
* I've run parts of the test suite with
EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
There are a few failures due to the things not currently implemented
(see above).
Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1562
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: docs only
Reviewers: austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also updates the user's guide to refer to the `-W`-based warning
flags by default.
Quoting the release note entry:
| Warnings can now be controlled with `-W(no-)...` flags in addition to
| the old `-f(no-)warn...` ones. This was done as the first part of a
| rewrite of the warning system to provide better control over warnings,
| better warning messages, and more common syntax compared to other
| compilers. The old `-fwarn...`-based warning flags will remain
| functional for the forseeable future.
This is part of
https://ghc.haskell.org/wiki/Design/Warnings
and addresses #11218
Reviewed By: hvr, bgamari
Differential Revision: https://phabricator.haskell.org/D1613
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes `template-haskell` functions for querying the language
extensions which are enabled when compiling a module,
- an `isExtEnabled` function to check whether an extension is enabled
- an `extsEnabled` function to obtain a full list of enabled extensions
To avoid code duplication this adds a `GHC.LanguageExtensions` module to
`ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
consequence of this is that the ungainly `DynFlags` lost around 500
lines. Moreover, flags corresponding to language extensions are now
clearly distinguished from other flags due to the `LangExt.*` prefix.
Updates haddock submodule.
This fixes #10820.
Test Plan: validate
Reviewers: austin, spinda, hvr, goldfire, alanz
Reviewed By: goldfire
Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
Differential Revision: https://phabricator.haskell.org/D1200
GHC Trac Issues: #10820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fulfils the request in Trac #11067, #10318, and #10592,
by lifting the conservative restrictions on superclass constraints.
These restrictions are there (and have been since Haskell was born) to
ensure that the transitive superclasses of a class constraint is a finite
set. However (a) this restriction is conservative, and can be annoying
when there really is no recursion, and (b) sometimes genuinely recursive
superclasses are useful (see the tickets).
Dimitrios and I worked out that there is actually a relatively simple way
to do the job. It’s described in some detail in
Note [The superclass story] in TcCanonical
Note [Expanding superclasses] in TcType
In brief, the idea is to expand superclasses only finitely, but to
iterate (using a loop that already existed) if there are more
superclasses to explore.
Other small things
- I improved grouping of error messages a bit in TcErrors
- I re-centred the haddock.compiler test, which was at 9.8%
above the norm, and which this patch pushed slightly over
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Reviewed By: austin, bgamari
Differential Revision: https://phabricator.haskell.org/D1606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are currently 2 different ways to test for a static or dynamic
build:
* Test if WayDyn is in ways
* Test if Opt_Static is set
The problem is that these can easily go out of sync, especially when
using the
GHC API.
This commit replaces all queries of Opt_Static with an equivalent query
of
WayDyn. This would have prevented bug #8294 and fixes #11154.
Reviewers: hvr, austin, bgamari
Reviewed By: austin, bgamari
Differential Revision: https://phabricator.haskell.org/D1607
GHC Trac Issues: #10636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in #4426 these warnings are now errors since the Great
Wildcards Refactor of 2015 (1e041b7382b6aa329e4ad9625439f811e0f27232).
I've opened #11221 to ensure we remove the last traces of the option in
8.2.
Test Plan: validate
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1615
GHC Trac Issues: #4426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #11182.
Reviewers: bgamari, simonpj, austin
Reviewed By: simonpj, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1592
GHC Trac Issues: #11182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a warning when a pattern synonym is not accompanied by a
signature in the style of `-fwarn-missing-sigs`.
It is turned on by -Wall.
If the user specifies, `-fwarn-missing-exported-signatures` with
`-fwarn-missing-pat-syn-sigs` then it will only warn when the pattern
synonym is exported.
Test Plan: ./validate
Reviewers: hvr, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1596
GHC Trac Issues: #11053
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Frontend plugins enable users to write plugins to replace
GHC major modes. E.g. instead of saying
ghc --make A B C
a user can now say
ghc --frontend GHC.Frontend.Shake A B C
which might provide an alternative implementation of a multi-module
build. For more details, see the manual entry.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonmar, bgamari, austin, simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1598
GHC Trac Issues: #11194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the ideas originally put forward in
"System FC with Explicit Kind Equality" (ICFP'13).
There are several noteworthy changes with this patch:
* We now have casts in types. These change the kind
of a type. See new constructor `CastTy`.
* All types and all constructors can be promoted.
This includes GADT constructors. GADT pattern matches
take place in type family equations. In Core,
types can now be applied to coercions via the
`CoercionTy` constructor.
* Coercions can now be heterogeneous, relating types
of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
proves both that `t1` and `t2` are the same and also that
`k1` and `k2` are the same.
* The `Coercion` type has been significantly enhanced.
The documentation in `docs/core-spec/core-spec.pdf` reflects
the new reality.
* The type of `*` is now `*`. No more `BOX`.
* Users can write explicit kind variables in their code,
anywhere they can write type variables. For backward compatibility,
automatic inference of kind-variable binding is still permitted.
* The new extension `TypeInType` turns on the new user-facing
features.
* Type families and synonyms are now promoted to kinds. This causes
trouble with parsing `*`, leading to the somewhat awkward new
`HsAppsTy` constructor for `HsType`. This is dispatched with in
the renamer, where the kind `*` can be told apart from a
type-level multiplication operator. Without `-XTypeInType` the
old behavior persists. With `-XTypeInType`, you need to import
`Data.Kind` to get `*`, also known as `Type`.
* The kind-checking algorithms in TcHsType have been significantly
rewritten to allow for enhanced kinds.
* The new features are still quite experimental and may be in flux.
* TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
* TODO: Update user manual.
Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
Updates Haddock submodule.
|
| |
|
|
|
|
|
|
| |
This is a fixup to fd3b845c01aa26b6e5cd12c00af59e5468e21b1b
which didn't take into account 09333313f32be975faf9158fcd3648489d78ad82
having pushed as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ideally, we'd have the more general
instance (MonadTrans t, Monad m, HasDynFlags m) => HasDynFlags (t m) where
getDynFlags = lift getDynFlags
definition. However, that one would overlap with the `HasDynFlags (GhcT m)`
instance. Instead we define instances for a couple of common Monad
transformers explicitly in order to avoid nasty overlapping instances.
This is a preparatory refactoring for #10874
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similiar to the `-fwarn-noncanonical-monad-instances` warning
implemented via #11128, but applies to `Semigroup`/`Monoid` instead
and the `(<>)`/`mappend` methods (of which `mappend` is planned to move
out of `Monoid` at some point in the future being redundant and thus
error-prone).
This warning is contained in `-Wcompat` but not in `-Wall`.
This addresses #11150
Reviewed By: quchen
Differential Revision: https://phabricator.haskell.org/D1553
|
|
|
|
|
| |
This reverts commit 8cba907ad404ba4005558b5a8966390159938172 which
broke `-ddump-to-file`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch creates empty dump file when GHC was run with
`-ddump-rule-firings` (or `-ddump-rule-rewrites`) and `-ddump-to-file`
specified, and there were no rules applied. If dump already exists it
will be overwritten by empty one.
Test Plan: ./validate
Reviewers: austin, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: thomie
Projects: #ghc
Differential Revision: https://phabricator.haskell.org/D1514
GHC Trac Issues: #10320
|
|
|
|
|
|
| |
Reviewed By: bgamari, austin
Differential Revision: https://phabricator.haskell.org/D1552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is similar to the AMP patch (#8004), which offered two
functions:
1. Warn when an instance of a class has been given, but the type does
not have a certain superclass instance
2. Warn when top-level definitions conflict with future Prelude names
These warnings are issued as part of the new `-Wcompat` warning group.
Reviewers: hvr, ekmett, austin, bgamari
Reviewed By: hvr, ekmett, bgamari
Subscribers: ekmett, thomie
Differential Revision: https://phabricator.haskell.org/D1539
GHC Trac Issues: #11139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since f16ddcee0c64a92ab911a7841a8cf64e3ac671fd / D876, `ghc-stage1`
supports a subset of `-XTemplateHaskell`, but since we need Cabal to be
able detect (so `.cabal` files can be specified accordingly, see also
GHC #11102 which omits `TemplateHaskell` from `--supported-extensions`)
whether GHC provides full or only partial `-XTemplateHaskell` support,
the proper way to accomplish this is to split off the
quotation/non-splicing `TemplateHaskell` feature-subset into a new
language pragma `TemplateHaskellQuotes`.
Moreover, `-XTemplateHaskellQuotes` is considered safe under SafeHaskell
This addresses #11121
Reviewers: goldfire, ezyang, dterei, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1511
GHC Trac Issues: #11121
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hvr, austin, thomie, bgamari
Reviewed By: hvr, austin, thomie, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1495
GHC Trac Issues: #11000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Warn about incoherent/non-canonical 'Applicative'/'Monad' instance
declarations. Specifically the following invariants are checked:
In 'Monad' instances declarations warn if the any of the following
conditions does not hold:
* If `return` is overridden it must be canonical (i.e. `return = pure`).
* If `(>>)` is overridden it must be canonical (i.e. `(>>) = (*>)`).
In 'Applicative' instance declarations:
* Warn if 'pure' is defined backwards (i.e. `pure = return`).
* Warn if '(*>)' is defined backwards (i.e. `(*>) = (>>)`).
NB, this warning flag is not enabled via `-Wall` nor `-Wcompat`.
This addresses #11128
Reviewers: quchen, austin, bgamari
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1516
|
|
|
|
|
|
|
|
|
| |
We now only strip block information from DebugBlocks when compiling with
`-g1`, intended to be used when only minimal debug information is
desired. `-g2` is assumed when `-g` is passed without any integer
argument.
Differential Revision: https://phabricator.haskell.org/D1281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC needs to be aware of targetting AIX because
AIX requires some special handling for the toolchain
(similiar to Solaris)
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1501
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`-XTemplateHaskell` requires GHCi; don't show it in
`--supported-extensions` if it's not supported.
Together with https://github.com/haskell/cabal/issues/2644
this allows to finally fix a long-standing annoyance in cabal
of not being able to detect availability of TH in build-plans.
Fixes #11102
See also https://github.com/haskell/cabal/pull/2930 which provides
emulation of this feature for older GHCs.
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements phase 1 of the MonadFail proposal (MFP, #10751).
- MonadFail warnings are all issued as desired, tunable with two new flags
- GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings`
(but it's disabled by default right now)
Credits/thanks to
- Franz Thoma, whose help was crucial to implementing this
- My employer TNG Technology Consulting GmbH for partially funding us
for this work
Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma
Reviewed By: hvr, bgamari, fmthoma
Subscribers: thomie
Projects: #ghc
Differential Revision: https://phabricator.haskell.org/D1248
GHC Trac Issues: #10751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/OverloadedLabels
for the big picture.
Reviewers: goldfire, simonpj, austin, hvr, bgamari
Reviewed By: simonpj, bgamari
Subscribers: kosmikus, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new language extension `-XStrict` which turns all bindings strict
as if the programmer had written a `!` before it. This also upgrades
ordinary Haskell to allow recursive and polymorphic strict bindings.
See the wiki[1] and the Note [Desugar Strict binds] in DsBinds for
specification and implementation details.
[1] https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
Reviewers: austin, tibbe, simonpj, bgamari
Reviewed By: tibbe, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1142
GHC Trac Issues: #8347
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|