summaryrefslogtreecommitdiff
path: root/compiler/main/DynFlags.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix some typosRik Steenkamp2016-01-161-1/+1
| | | | Differential Revision: https://phabricator.haskell.org/D1785
* Fix #11405.Richard Eisenberg2016-01-151-2/+2
| | | | | | | 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.
* Rename InjectiveTypeFamilies to TypeFamilyDependenciesBen Gamari2016-01-141-2/+2
|
* Add InjectiveTypeFamilies language extensionJan Stolarek2016-01-091-1/+3
| | | | | | | | | | | | | | | | | 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
* Add a note describing the protocol for adding a language extensionBen Gamari2016-01-061-0/+54
| | | | | | | | | | | | Reviewers: hvr, thomie, austin Reviewed By: austin Subscribers: duncan Differential Revision: https://phabricator.haskell.org/D1741 GHC Trac Issues: #8176, #4437
* Extend ghc environment file featuresDuncan Coutts2016-01-051-24/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove -Wtoo-many-guards from default flags (fixes #11316)George Karachalias2016-01-051-1/+0
| | | | | | | | | | | | | | | | | | 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
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-311-5/+0
| | | | | | | | | | | | 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
* Adding flags: -ffull-guard-reasoning and too-many-guardsGeorge Karachalias2015-12-271-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Visible type applicationRichard Eisenberg2015-12-241-0/+2
| | | | | | | | | | | | | 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.
* Implement -hide-all-plugin-packages and -plugin-package(-id), fixing #11244Edward Z. Yang2015-12-221-12/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor package flags into several distinct types.Edward Z. Yang2015-12-221-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Maintain cost-centre stacks in the interpreterSimon Marlow2015-12-211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DynFlags: call defaultWays when creating defaultFlagsThomas Miedema2015-12-211-3/+1
| | | | | | | | | | | | | | | 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
* Add -fprint-typechecker-elaboration flag (fixes #10662)Eugene Akentyev2015-12-171-0/+2
| | | | | | | | | | | | Reviewers: thomie, austin, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1625 GHC Trac Issues: #10662
* Build system: Make cGhcRtsWithLibdw flag a proper BoolBen Gamari2015-12-171-8/+7
| | | | | | | | | | | | Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1642
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-28/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* GHC doesn't have a way to ask for user-package-db, so Cabal reimplemented it.Edward Z. Yang2015-12-161-0/+2
| | | | | | | | | | | | 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
* Add `-W(no-)xxx` aliases for `-f(no-)warn-xxx` flagsDavid Luposchainsky2015-12-161-82/+94
| | | | | | | | | | | | | | | | | | | | | | 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
* Expose enabled language extensions to THBen Gamari2015-12-151-338/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Allow recursive (undecidable) superclassesSimon Peyton Jones2015-12-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DynFlags: delete function that doesn't do anythingThomas Miedema2015-12-151-12/+3
| | | | | | | | Reviewers: austin, bgamari Reviewed By: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1606
* DynFlags: remove Opt_StaticThomas Miedema2015-12-151-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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
* DynFlags Remove -fwarn-context-quantification flagBen Gamari2015-12-151-3/+3
| | | | | | | | | | | | | | | | | 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
* Make -XStrict imply -XStrictDataAdam Sandberg Eriksson2015-12-121-0/+1
| | | | | | | | | | | | | | Fixes #11182. Reviewers: bgamari, simonpj, austin Reviewed By: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1592 GHC Trac Issues: #11182
* Implement -fwarn-missing-pat-syn-sigsMatthew Pickering2015-12-121-2/+5
| | | | | | | | | | | | | | | | | | | | | | | 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
* Frontend plugins.Edward Z. Yang2015-12-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix typo sneaked in with fd3b845c01aa26b6e5Herbert Valerio Riedel2015-12-081-2/+2
|
* Fix double MaybeT instanceHerbert Valerio Riedel2015-12-081-4/+0
| | | | | | This is a fixup to fd3b845c01aa26b6e5cd12c00af59e5468e21b1b which didn't take into account 09333313f32be975faf9158fcd3648489d78ad82 having pushed as well.
* Make HasDynFlags more transformers friendlyHerbert Valerio Riedel2015-12-081-0/+35
| | | | | | | | | | | | | | | | | 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
* Implement new `-fwarn-noncanonical-monoid-instances`Herbert Valerio Riedel2015-12-061-1/+5
| | | | | | | | | | | | | | | | 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
* Revert "Create empty dump files when there was nothing to dump"Ben Gamari2015-12-031-2/+2
| | | | | This reverts commit 8cba907ad404ba4005558b5a8966390159938172 which broke `-ddump-to-file`.
* Create empty dump files when there was nothing to dumpVladimir Trubilov2015-12-021-2/+2
| | | | | | | | | | | | | | | | | | | | | 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
* Move Stg-specific code from DynFlags to SimplStgÖmer Sinan Ağacan2015-12-021-26/+0
| | | | | | Reviewed By: bgamari, austin Differential Revision: https://phabricator.haskell.org/D1552
* Implement warnings for Semigroups as parent of MonoidDavid Luposchainsky2015-11-291-1/+4
| | | | | | | | | | | | | | | | | | | | | 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
* Implement new -XTemplateHaskellQuotes pragmaHerbert Valerio Riedel2015-11-291-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* DynFlags: Drop stale commentBen Gamari2015-11-241-2/+1
|
* DynFlags: Update comments to reflect new users guideBen Gamari2015-11-241-6/+7
|
* Add -Wcompat warning flag groupDavid Luposchainsky2015-11-241-9/+22
| | | | | | | | | | | | Reviewers: hvr, austin, thomie, bgamari Reviewed By: hvr, austin, thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1495 GHC Trac Issues: #11000
* Implement new `-fwarn-noncanonical-monad-instances`Herbert Valerio Riedel2015-11-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support multiple debug output levelsBen Gamari2015-11-231-4/+6
| | | | | | | | | 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
* Make GHC aware of OSAIX and AixLDHerbert Valerio Riedel2015-11-191-0/+1
| | | | | | | | | | | | | | 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
* Mention "-XMonadFailDesugaring" in the docsDavid Luposchainsky2015-11-181-2/+2
| | | | | | | | Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1496
* Disable failed specialisation warnings by default & update documentation.Ben Gamari2015-11-181-4/+2
| | | | | | | | | | | | | | | | | | 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
* DynFlags: Don't list TemplateHaskell as supported if it's notBen Gamari2015-11-181-2/+13
| | | | | | | | | | | | | | | | | | `-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
* MonadFail proposal, phase 1David Luposchainsky2015-11-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement OverloadedLabelsAdam Gundry2015-11-171-0/+2
| | | | | | | | | | | | | | 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
* Implement the Strict language extensionAdam Sandberg Eriksson2015-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | | 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
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-121-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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