1. 11 Feb, 2016 2 commits
  2. 09 Feb, 2016 2 commits
  3. 04 Feb, 2016 1 commit
    • Georgios Karachalias's avatar
      Overhaul the Overhauled Pattern Match Checker · 28f951ed
      Georgios Karachalias authored
      Overhaul the Overhauled Pattern Match Checker
      
      * Changed the representation of Value Set Abstractions. Instead of
      using a prefix tree, we now use a list of Value Vector Abstractions.
      The set of constraints Delta for every Value Vector Abstraction is the
      oracle state so that we solve everything only once.
      
      * Instead of doing everything lazily, we prune at once (and in general
      everything is much stricter). Hence, an example written with pattern
      guards is checked in almost the same time as the equivalent with
      pattern matching.
      
      * Do not store the covered and the divergent sets at all. Since what we
      only need is a yes/no (does this clause cover anything? Does it force
      any thunk?) We just keep a boolean for each.
      
      * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`.
      Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should
      the default `n` be.
      
      * When a guard is for sure not going to contribute anything, we treat
      it as such: The oracle is not called and cases `CGuard`, `UGuard` and
      `DGuard` from the paper are not happening at all (the generation of a
      fresh variable, the unfolding of the pattern list etc.). his combined
      with the above seems to be enough to drop the memory increase for test
      T783 down to 18.7%.
      
      * Do not export function `dsPmWarn` (it is now called directly from
      within `checkSingle` and `checkMatches`).
      
      * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle
      does not handle type information so using `Id` was a waste of
      time/space.
      
      * Added testcases T11195, T11303b (data families) and T11374
      
      The patch addresses at least the following:
      Trac #11195, #11276, #11303, #11374, #11162
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, hvr, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1795
      28f951ed
  4. 01 Feb, 2016 2 commits
    • Oleg Grenrus's avatar
      Add some Outputable instances · 2ad46a86
      Oleg Grenrus authored
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1865
      2ad46a86
    • Herbert Valerio Riedel's avatar
      Implement basic uniform warning set tower · 86897e1f
      Herbert Valerio Riedel authored
      This implements/completes the current basic warning sets to provide the
      following tower of warning sets (i.e. each line subsumes the warnings
      from the sets listed below):
      
      - `-Weverything`
      - `-Wall`
      - `-Wextra` (alias of `-W`)
      - `-Wdefault`
      
      So for each of flags there's also a complement `-Wno-...` flag, which
      subtracts the given set from the current enabled-warnings state.
      
      Thus, we can now easily perform simple set subtraction operations, as
      warning flags are evaluated from left-to-right on the command line.
      
      So e.g.
      
      - `-Weverything -Wno-all -Wno-compat` enables *all* warnings not enabled
        by `-Wall` and `-Wcompat`.
      
      - `-Wextra -Wno-default` only warnings that `-Wextra` provides
        beyond the default warnings.
      
      Reviewers: quchen, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1850
      86897e1f
  5. 27 Jan, 2016 3 commits
    • rwbarton's avatar
      Test for undef bugs in the LLVM backend when validating · d50609e8
      rwbarton authored
      In an attempt to catch bugs involving using undef values, replace
      undef literals by values likely to cause crashes or test failures.
      We do this only when validating since it is a deoptimization.
      
      This depends on D1857 to catch such bugs in the RTS (such as #11487).
      
      Test Plan:
      Did a build with
      ```
      BuildFlavour = quick-llvm
      SRC_HC_OPTS_STAGE1 = -fllvm-fill-undef-with-garbage
      ```
      The build crashed when running ghc-stage2, as expected.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1858
      d50609e8
    • triple's avatar
      ghci: fix trac issue #11481 · 1f6d1422
      triple authored
      Test Plan: validate
      
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1833
      
      GHC Trac Issues: #11481
      1f6d1422
    • Tamar Christina's avatar
      Enable RemoteGHCi on Windows · 44a5d51a
      Tamar Christina authored
      Makes the needed changes to make RemoteGHCi work on Windows.
      The approach passes OS Handles areound instead of the Posix Fd
      as on Linux.
      
      The reason is that I could not find any real documentation about
      the behaviour of Windows w.r.t inheritance and Posix FDs.
      
      The implementation with Fd did not seem to be able to find the Fd
      in the child process. Instead I'm using the much better documented
      approach of passing inheriting handles.
      
      This requires a small modification to the `process` library.
      https://github.com/haskell/process/pull/52
      
      Test Plan: ./validate On Windows x86_64
      
      Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr
      
      Reviewed By: simonmar
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1836
      
      GHC Trac Issues: #11100
      44a5d51a
  6. 26 Jan, 2016 1 commit
    • Ryan Scott's avatar
      Split off -Wunused-type-variables from -Wunused-matches · 6817703b
      Ryan Scott authored
      Summary:
      Previously, `-Wunused-matches` would fire whenever it detected unused type
      variables in a type family or data family instance. This can be annoying for
      users who wish to use type variable names as documentation, as being
      `-Wall`-compliant would mean that they'd have to prefix many of their type
      variable names with underscores, making the documentation harder to read.
      
      To avoid this, a new warning `-Wunused-type-variables` was created that only
      encompasses unused variables in family instances. `-Wunused-matches` reverts
      back to its role of only warning on unused term-level pattern names. Unlike
      `-Wunused-matches`, `-Wunused-type-variables` is not implied by `-Wall`.
      
      Fixes #11451.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, ekmett, austin, hvr, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1825
      
      GHC Trac Issues: #11451
      6817703b
  7. 25 Jan, 2016 2 commits
  8. 24 Jan, 2016 2 commits
    • Herbert Valerio Riedel's avatar
      Implement `-Wnoncanonical-monadfail-instances` warning · fd6dd41c
      Herbert Valerio Riedel authored
      The MonadFail proposal implemented so far via #10751 only warns about
      missing `MonadFail` instances based on existence of failible pattern
      matches in `do`-blocks.
      
      However, based on the noncanonical Monad warnings implemented via #11150
      we can provide a different mechanism for detecting missing `MonadFail`
      instances quite cheaply. That is, by checking for canonical `fail` definitions.
      
      In the case of `Monad`/`MonadFail`, we define the canonical implementation of
      `fail` to be such that the soft-deprecated method shall (iff overridden) be
      defined in terms of the non-deprecated method. Consequently, in case of
      `MonadFail`, the `Monad(fail)` method shall be defined as alias of
      the `MonadFail(fail)` method.
      
      This allows us at some distant point in the future to remove `fail` from
      the `Monad` class, while having GHC ignore/tolerate such literal canonical
      method definitions.
      
      Reviewed By: bgamari, RyanGlScott
      
      Differential Revision: https://phabricator.haskell.org/D1838
      fd6dd41c
    • thomie's avatar
      Remove `replaceDynFlags` from `ContainsDynFlags` · edc68b2f
      thomie authored
      Refactoring only. It's shorter, and brings
      `HasDynFlags/ContainsDynFLags` in line with `HasModule/ContainsModule`.
      Introduce `updTopEnv`.
      
      Reviewed by: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1832
      edc68b2f
  9. 23 Jan, 2016 1 commit
  10. 18 Jan, 2016 2 commits
    • Edward Z. Yang's avatar
      Switch from -this-package-key to -this-unit-id. · 240ddd7c
      Edward Z. Yang authored
      A small cosmetic change, but we have to do a bit of work to
      actually support it:
      
          - Cabal submodule update, so that Cabal passes us
            -this-unit-id when we ask for it.  This includes
            a Cabal renaming to be consistent with Unit ID, which
            makes ghc-pkg a bit more scrutable.
      
          - Build system is updated to use -this-unit-id rather than
            -this-package-key, to avoid deprecation warnings.  Needs
            a version test so I resurrected the old test we had
            (sorry rwbarton!)
      
          - I've *undeprecated* -package-name, so that we are in the same
            state as GHC 7.10, since the "correct" flag will have only
            entered circulation in GHC 8.0.
      
          - I removed -package-key.  Since we didn't deprecate -package-id
            I think this should not cause any problems for users; they
            can just change their code to use -package-id.
      
          - The package database is indexed by UNIT IDs, not component IDs.
            I updated the naming here.
      
          - I dropped the signatures field from ExposedModule; nothing
            was using it, and instantiatedWith from the package database
            field.
      
          - ghc-pkg was updated to use unit ID nomenclature, I removed
            the -package-key flags but I decided not to add any new flags
            for now.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: 23Skidoo, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1780
      240ddd7c
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  11. 16 Jan, 2016 1 commit
  12. 15 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11405. · 3c6635ef
      eir@cis.upenn.edu authored
      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.
      3c6635ef
  13. 14 Jan, 2016 1 commit
  14. 09 Jan, 2016 1 commit
  15. 06 Jan, 2016 1 commit
  16. 05 Jan, 2016 2 commits
    • Duncan Coutts's avatar
      Extend ghc environment file features · aa699b94
      Duncan Coutts authored
      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
      aa699b94
    • Georgios Karachalias's avatar
      Remove -Wtoo-many-guards from default flags (fixes #11316) · 77494fa9
      Georgios Karachalias authored
      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
      77494fa9
  17. 31 Dec, 2015 1 commit
  18. 27 Dec, 2015 1 commit
    • Georgios Karachalias's avatar
      Adding flags: -ffull-guard-reasoning and too-many-guards · bec5350d
      Georgios Karachalias authored
      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
      bec5350d
  19. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      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.
      2db18b81
  20. 22 Dec, 2015 2 commits
    • Edward Z. Yang's avatar
      Implement -hide-all-plugin-packages and -plugin-package(-id), fixing #11244 · 1faf1fca
      Edward Z. Yang authored
      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: default avatarEdward 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
      1faf1fca
    • Edward Z. Yang's avatar
      Refactor package flags into several distinct types. · 998739df
      Edward Z. Yang authored
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, duncan
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1659
      998739df
  21. 21 Dec, 2015 2 commits
    • Simon Marlow's avatar
      Maintain cost-centre stacks in the interpreter · c8c44fd9
      Simon Marlow authored
      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
      c8c44fd9
    • thomie's avatar
      DynFlags: call defaultWays when creating defaultFlags · 29ca4a19
      thomie authored
      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
      29ca4a19
  22. 17 Dec, 2015 4 commits
    • Eugene Akentyev's avatar
      Add -fprint-typechecker-elaboration flag (fixes #10662) · d3dac4e3
      Eugene Akentyev authored
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1625
      
      GHC Trac Issues: #10662
      d3dac4e3
    • Ben Gamari's avatar
      Build system: Make cGhcRtsWithLibdw flag a proper Bool · 109d8479
      Ben Gamari authored
      Test Plan: validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1642
      109d8479
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      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
      4905b83a
    • Edward Z. Yang's avatar
      GHC doesn't have a way to ask for user-package-db, so Cabal reimplemented it. · 7221ad70
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: docs only
      
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1644
      7221ad70
  23. 16 Dec, 2015 1 commit
    • quchen's avatar
      Add `-W(no-)xxx` aliases for `-f(no-)warn-xxx` flags · 2206fa8c
      quchen authored
      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
      2206fa8c
  24. 15 Dec, 2015 3 commits
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      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
      c1e25536
    • Simon Peyton Jones's avatar
      Allow recursive (undecidable) superclasses · 6eabb6dd
      Simon Peyton Jones authored
      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
      6eabb6dd
    • thomie's avatar
      DynFlags: delete function that doesn't do anything · 33742db5
      thomie authored
      Reviewers: austin, bgamari
      
      Reviewed By: austin, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1606
      33742db5