1. 24 May, 2016 1 commit
    • niteria's avatar
      Document some benign nondeterminism · 4c6e69d5
      niteria authored
      I've changed the functions to their nonDet equivalents and explained
      why they're OK there. This allowed me to remove foldNameSet,
      foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly.
      
      Test Plan: ./validate, there should be no change in behavior
      
      Reviewers: simonpj, simonmar, austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2244
      
      GHC Trac Issues: #4012
      4c6e69d5
  2. 22 May, 2016 1 commit
  3. 18 May, 2016 1 commit
    • Dave Laing's avatar
      Rework parser to allow use with DynFlags · 39a2faa0
      Dave Laing authored
      Split out the options needed by the parser from DynFlags, making the
      parser more friendly to standalone usage.
      
      Test Plan: validate
      
      Reviewers: simonmar, alanz, bgamari, austin, thomie
      
      Reviewed By: simonmar, alanz, bgamari, thomie
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2208
      
      GHC Trac Issues: #10961
      39a2faa0
  4. 16 May, 2016 1 commit
    • Ben Gamari's avatar
      Move Extension type to ghc-boot-th · eed820b6
      Ben Gamari authored
      This creates a new package, `ghc-boot-th`, to contain the `Extension`
      type, which now lives in `GHC.LanguageExtension.Type`. This ensures that
      the transitive dependency set of the `template-haskell` package remains
      minimal.
      
      The `GHC.LanguageExtensions.Type` module is also re-exported by
      `ghc-boot`, which provides an orphan `binary` instance as well.
      
      Test Plan: Validate
      
      Reviewers: goldfire, thomie, hvr, austin
      
      Reviewed By: thomie
      
      Subscribers: RyanGlScott, thomie, erikd, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D2224
      eed820b6
  5. 12 May, 2016 1 commit
  6. 10 May, 2016 1 commit
  7. 02 May, 2016 2 commits
    • Facundo Domínguez's avatar
      StaticPointers: Allow closed vars in the static form. · 36d29f7c
      Facundo Domínguez authored
      Summary:
      With this patch closed variables are allowed regardless of whether
      they are bound at the top level or not.
      
      The FloatOut pass is always performed. When optimizations are
      disabled, only expressions that go to the top level are floated.
      Thus, the applications of the StaticPtr data constructor are always
      floated.
      
      The CoreTidy pass makes sure the floated applications appear in the
      symbol table of object files. It also collects the floated bindings
      and inserts them in the static pointer table.
      
      The renamer does not check anymore if free variables appearing in the
      static form are top-level. Instead, the typechecker looks at the
      tct_closed flag to decide if the free variables are closed.
      
      The linter checks that applications of StaticPtr only occur at the
      top of top-level bindings after the FloatOut pass.
      
      The field spInfoName of StaticPtrInfo has been removed. It used to
      contain the name of the top-level binding that contains the StaticPtr
      application. However, this information is no longer available when the
      StaticPtr is constructed, as the binding name is determined now by the
      FloatOut pass.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, mpickering, mboes
      
      Differential Revision: https://phabricator.haskell.org/D2104
      
      GHC Trac Issues: #11656
      36d29f7c
    • Sergei Trofimovich's avatar
      db2bfe00
  8. 01 May, 2016 1 commit
  9. 22 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Warn about simplifiable class constraints · 9421b0c7
      Simon Peyton Jones authored
      Provoked by Trac #11948, this patch adds a new warning to GHC
      
        -Wsimplifiable-class-constraints
      
      It warns if you write a class constraint in a type signature that
      can be simplified by an existing instance declaration.  Almost always
      this means you should simplify it right now; type inference is very
      fragile without it, as #11948 shows.
      
      I've put the warning as on-by-default, but I suppose that if there are
      howls of protest we can move it out (as happened for -Wredundant-constraints.
      
      It actually found an example of an over-complicated context in CmmNode.
      
      Quite a few tests use these weird contexts to trigger something else,
      so I had to suppress the warning in those.
      
      The 'haskeline' library has a few occurrences of the warning (which
      I think should be fixed), so I switched it off for that library in
      warnings.mk.
      
      The warning itself is done in TcValidity.check_class_pred.
      
      HOWEVER, when type inference fails we get a type error; and the error
      suppresses the (informative) warning.  So as things stand, the warning
      only happens when it doesn't cause a problem.  Not sure what to do
      about this, but this patch takes us forward, I think.
      9421b0c7
  10. 20 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Reduce use of instances in hs-boot files · 81aa3d1c
      Simon Peyton Jones authored
      Several things here
      
      * GHC no longer allows user-written Typeable instances,
        so remove them from hs-boot files.
      
      * Generally, reduce the use of instances in hs-boot files. They are
        hard to track.  Mainly this involves using pprType, pprKind etc
        instead of just ppr.  There were a lot of instances in hs-boot
        files that weren't needed at all.
      
      * Take TyThing out of Eq; it was used in exactly one place (in
        InteractiveEval), and equality is too big a hammer for that.
      81aa3d1c
  11. 19 Apr, 2016 1 commit
  12. 17 Apr, 2016 2 commits
    • Tamar Christina's avatar
      Resolve symlinks when attempting to find GHC's lib folder on Windows · a3922083
      Tamar Christina authored
      Summary:
      Systools makes some pretty hard assumptions about where GHC is on Windows.
      One of these is that ghc be in a folder named `bin` and that `../lib` exists.
      
      This pattern doesn't hold for symlinks as a link `C:\ghc-bin\`
      pointing to `C:\ghc\ghc-7.10.3\bin` will break this assumption.
      
      This patch resolves symlinks by finding where they point to and uses that location
      as the base for GHC.
      
      This uses an API that's been introduced in Vista. For older systems it falls back to
      the current behavior of not resolving symlinks.
      
      Test Plan:
      1) Create symlink to GHC's bin folder.
      2) Run GHC from that folder.
      
      Reviewers: austin, bgamari
      
      Reviewed By: austin
      
      Subscribers: #ghc_windows_task_force, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2101
      
      GHC Trac Issues: #11759
      a3922083
    • quchen's avatar
      Add flag to control number of missing patterns in warnings · 7005b9f7
      quchen authored
      Non-exhaustive pattern warnings had their number of patterns to
      show hardcoded in the past. This patch implements the TODO remark
      that this should be made a command line flag.
      
          -fmax-uncovered-patterns=<n>
      
      can now be used to influence the number of patterns to be shown.
      
      Reviewers: hvr, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2076
      7005b9f7
  13. 15 Apr, 2016 1 commit
    • niteria's avatar
      Kill some unnecessary varSetElems · 928d7473
      niteria authored
      When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to
      `tyCoVarsOfTypeList x`.
      
      Why? If you look at the implementation:
      ```
      tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty
      tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty
      ```
      they use the same helper function. The helper function returns a
      deterministically ordered list and a set. The only difference
      between the two is which part of the result they take. It is redundant
      to take the set and then immediately convert it to a list.
      
      This helps with determinism and we eventually want to replace the uses
      of `varSetElems` with functions that don't leak the values of uniques.
      This change gets rid of some instances that are easy to kill.
      
      I chose not to annotate every place where I got rid of `varSetElems`
      with a comment about non-determinism, because once we get rid of
      `varSetElems` it will not be possible to do the wrong thing.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, simonmar, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2115
      
      GHC Trac Issues: #4012
      928d7473
  14. 14 Apr, 2016 1 commit
  15. 10 Apr, 2016 2 commits
    • Tamar Christina's avatar
      Change runtime linker to perform lazy loading of symbols/sections · 90538d86
      Tamar Christina authored
      The Runtime Linker is currently eagerly loading all object files on all
      platforms which do not use the system linker for `GHCi`.
      
      The problem with this approach is that it requires all symbols to be
      found.  Even those of functions never used/called. This makes the number
      of libraries required to link things like `mingwex` quite high.
      
      To work around this the `rts` was relying on a trick. It itself was
      compiled with `MingW64-w`'s `GCC`. So it was already linked against
      `mingwex`.  As such, it re-exported the symbols from itself.
      
      While this worked it made it impossible to link against `mingwex` in
      user libraries. And with this means no `C99` code could ever run in
      `GHCi` on Windows without having the required symbols re-exported from
      the rts.
      
      Consequently this rules out a large number of packages on Windows.
      SDL2, HMatrix etc.
      
      After talking with @rwbarton I have taken the approach of loading entire
      object files when a symbol is needed instead of doing the dependency
      tracking on a per symbol basis. This is a lot less fragile and a lot
      less complicated to implement.
      
      The changes come down to the following steps:
      
      1) modify the linker to and introduce a new state for ObjectCode:
         `Needed`.  A Needed object is one that is required for the linking to
         succeed.  The initial set consists of all Object files passed as
         arguments to the link.
      
      2) Change `ObjectCode`'s to be indexed but not initialized or resolved.
         This means we know where we would load the symbols,
         but haven't actually done so.
      
      3) Mark any `ObjectCode` belonging to `.o` passed as argument
         as required: ObjectState `NEEDED`.
      
      4) During `Resolve` object calls, mark all `ObjectCode`
         containing the required symbols as `NEEDED`
      
      5) During `lookupSymbol` lookups, (which is called from `linkExpr`
         and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded
         `ObjectCode` then load the `ObjectCode` on demand and return the
         address of the symbol. Otherwise produce an unresolved symbols error
         as expected.
      
      6) On `unloadObj` we then change the state of the object and remove
         it's symbols from the `reqSymHash` table so it can be reloaded.
      
      This change affects all platforms and OSes which use the runtime linker.
      It seems there are no real perf tests for `GHCi`, but performance
      shouldn't be impacted much. We gain a lot of time not loading all `obj`
      files, and we lose some time in `lookupSymbol` when we're finding
      sections that have to be loaded. The actual finding itself is O(1)
      (Assuming the hashtnl is perfect)
      
      It also consumes slighly more memory as instead of storing just the
      address of a symbol I also store some other information, like if the
      symbol is weak or not.
      
      This change will break any packages relying on renamed POSIX functions
      that were re-named and re-exported by the rts. Any packages following
      the proper naming for functions as found on MSDN will work fine.
      
      Test Plan: ./validate on all platforms which use the Runtime linker.
      
      Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr
      
      Reviewed By: erikd
      
      Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar,
                   rwbarton, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1805
      
      GHC Trac Issues: #11223
      90538d86
    • Herbert Valerio Riedel's avatar
      Reduce default for -fmax-pmcheck-iterations from 1e7 to 2e6 · d2e05c6b
      Herbert Valerio Riedel authored
      The commit 28f951ed introduced the
      `-fmax-pmcheck-iterations` flag and set the default limit to 1e7
      iterations.
      
      However, this value is still high enough that it can result GHC to
      exhibit memory spikes beyond 1 GiB of RAM usage (heap profile showed
      several `(:)`s, as well as `THUNK_2_0`, and `PmCon` during the memory
      spikes)
      
      A value of 2e6 seems to be a safer upper bound which still manages to
      let the checker not run into the limit in most cases.
      
      Test Plan: Validate, try building a few Hackage packages
      
      Reviewers: austin, gkaracha, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2095
      d2e05c6b
  16. 30 Mar, 2016 2 commits
  17. 29 Mar, 2016 1 commit
    • Joachim Breitner's avatar
      Rename isNopSig to isTopSig · e6e17a09
      Joachim Breitner authored
      to be consistent with the other uses of nop vs. top in Demand.hs. Also,
      stop prettyprinting top strictness signatures in Core dumps.
      e6e17a09
  18. 28 Mar, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Scrap DEC OSF/1 support · f911358b
      Herbert Valerio Riedel authored
      DEC OSF/1 (aka Tru64 UNIX) has been discontinued a few years ago already[1].
      
      This removes the undoubtedly bitrotten support for `OSOsf3 :: OS` from GHC's
      code-base.
      
      Support for `ArchAlpha :: Arch` may be removed at some later point, as there
      may still be users out there running a more or less recent Linux/alpha
      distribution on their more-than-a-decade old Alpha hardware...
      
       [1]: https://en.wikipedia.org/wiki/Tru64_UNIX
      f911358b
  19. 25 Mar, 2016 1 commit
    • Ben Gamari's avatar
      DynFlags: Initialize unsafeGlobalDynFlags enough to be useful · 4e98b4ff
      Ben Gamari authored
      Previously unsafeGlobalDynFlags would bottom if used prior to
      initialization. This meant that any attempt to use the pretty-printer
      early in the initialization process of the compiler would fail. This is
      quite inconvenient.
      
      Here we initialize unsafeGlobalDynFlags with defaultDynFlags, bottoming
      only if settings is accessed.
      
      See #11755.
      
      Test Plan: Validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie, gridaphobe
      
      Differential Revision: https://phabricator.haskell.org/D2036
      
      GHC Trac Issues: #11755
      4e98b4ff
  20. 24 Mar, 2016 4 commits
    • kaiha's avatar
      Add option `no-keep-hi-files` and `no-keep-o-files` (fixes #4114) · 24149528
      kaiha authored
      Summary: Remove `.hi` and `.o` files if the flags `no-keep-hi-files` and
      `no-keep-o-files` are given.
      
      Test Plan: ./validate
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2021
      
      GHC Trac Issues: #4114
      24149528
    • Ben Gamari's avatar
      Default RuntimeRep variables unless -fprint-explicit-runtime-reps · 371608f1
      Ben Gamari authored
      Summary:
      Addresses #11549 by defaulting `RuntimeRep` variables to `PtrRepLifted`
      and adding a new compiler flag `-fprint-explicit-runtime-reps` to
      disable this behavior.
      
      This is just a guess at the right way to go about this. If it's
      wrong-beyond-any-hope just say so.
      
      Test Plan: Working on a testcase
      
      Reviewers: goldfire, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1961
      
      GHC Trac Issues: #11549
      371608f1
    • Ben Gamari's avatar
      DsExpr: Rip out static/dynamic check in list desugaring · 0db05941
      Ben Gamari authored
      Previously we would try to break explicit lists into a dynamic prefix
      and static tail and desugar the former into a `build` expression.
      Unfortunately, this heuristic resulted in surprising behavior
      (see #11710) and wasn't pulling its weight. Here we drop it (along with
      the `-fsimple-list-literals` flag), leaving only the list length
      heuristic to determine whether `build` or cons list desugaring should be
      used.
      
      Test Plan: Validate
      
      Reviewers: simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2023
      
      GHC Trac Issues: #11710
      0db05941
    • Ben Gamari's avatar
      ErrUtils: Add timings to compiler phases · 8048d51b
      Ben Gamari authored
      This adds timings and allocation figures to the compiler's output when
      run with `-v2` in an effort to ease performance analysis.
      
      Todo:
        * Documentation
        * Where else should we add these?
        * Perhaps we should remove some of the now-arguably-redundant
          `showPass` occurrences where they are
        * Must we force more?
        * Perhaps we should place this behind a `-ftimings` instead of `-v2`
      
      Test Plan: `ghc -v2 Test.hs`, look at the output
      
      Reviewers: hvr, goldfire, simonmar, austin
      
      Reviewed By: simonmar
      
      Subscribers: angerman, michalt, niteria, ezyang, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1959
      8048d51b
  21. 21 Mar, 2016 1 commit
  22. 16 Mar, 2016 1 commit
    • Erik de Castro Lopo's avatar
      DriverPipeline: Fix 'unused arguments' warnings from Clang · 46f9a476
      Erik de Castro Lopo authored
      When using Clang as the C compiler, over 100 tests were failing
      due to Clang reporting that some command line arguments were not
      being used. These warnings only occur when Clang is compiling
      assembler files which happens in two places, one of which already
      conditionally adding `-Qunused-arguments` to the command line when
      the compiler was Clang. This fixes the other.
      
      Test Plan: validate with clang as the C compiler
      
      Reviewers: bgamari, hvr, austin, rwbarton
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1998
      
      GHC Trac Issues: #11684
      46f9a476
  23. 11 Mar, 2016 2 commits
    • Simon Marlow's avatar
      Add -foptimal-applicative-do · 2f45cf3f
      Simon Marlow authored
      Summary:
      The algorithm for ApplicativeDo rearrangement is based on a heuristic
      that runs in O(n^2).  This patch adds the optimal algorithm, which is
      O(n^3), selected by a flag (-foptimal-applicative-do).  It finds better
      solutions in a small number of cases (about 2% of the cases where
      ApplicativeDo makes a difference), but it can be very slow for large do
      expressions.  I'm mainly adding it for experimental reasons.
      
      ToDo: user guide docs
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin, niteria, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1969
      2f45cf3f
    • Ben Gamari's avatar
      Handle unset HOME environment variable more gracefully · 2908ae8d
      Ben Gamari authored
      Test Plan:
        * Validate
        * try `env -i ghc`
        * try `env -i runghc HelloWorld.hs`
      
      Reviewers: austin
      
      Subscribers: thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1971
      
      GHC Trac Issues: #11678
      2908ae8d
  24. 07 Mar, 2016 1 commit
  25. 05 Mar, 2016 1 commit
  26. 29 Feb, 2016 1 commit
  27. 27 Feb, 2016 2 commits
    • Herbert Valerio Riedel's avatar
      Default to -fno-show-warning-groups (re #10752) · 46f3775c
      Herbert Valerio Riedel authored
      As `-fno-show-warning-groups` shows associated warning groups regardless
      of whether the respective warning group flag as been passed on the CLI,
      the warning-group information may be confusing to users.
      
      At this point, `-fshow-warning-groups` is useful mostly to GHC
      developers and possibly GHC users who want to see which warning groups
      an emitted warning is part of. (Btw, this is particularly interesting in
      combination with `-Weverything` which enables *every* warning flag known
      to GHC.)
      
      Consequently, starting with this commit, one has to opt-in via
      `-fshow-warning-groups` for GHC to show warning groups.
      
      In order to reduce the testsuite delta in this commit, the
      `-fshow-warning-groups` flag has been added to TEST_HC_OPTS.
      46f3775c
    • Herbert Valerio Riedel's avatar
      Print which flag controls emitted SafeHaskell warnings · b6c61e37
      Herbert Valerio Riedel authored
      This is extends bb5afd3c to cover
      SafeHaskell warnings.
      
      This implements yet another part of #10752
      b6c61e37
  28. 26 Feb, 2016 1 commit
  29. 25 Feb, 2016 3 commits
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
    • manav's avatar
      Make warning names more consistent · 66584914
      manav authored
      - Replace "Sigs" with "Signatures" in WarningFlag data constructors.
      - Replace "PatSyn" with "PatternSynonym" in WarningFlag data
        constructors.
      - Deprecate "missing-local-sigs" in favor of "missing-local-signatures".
      - Deprecate "missing-exported-sigs" in favor of
        "missing-exported-signatures".
      - Deprecate "missing-pat-syn-signatures" in favor of
        "missing-pattern-synonym-signatures".
      - Replace "ddump-strsigs" with "ddump-str-signatures"
      
      These complete the tasks that were explicitly mentioned in #11583
      
      Test Plan:
      Executed `ghc --show-options` and verified that the flags were changed
      as expected.
      
      Reviewers: svenpanne, austin, bgamari
      
      Reviewed By: austin, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1939
      
      GHC Trac Issues: #11583
      66584914
    • Ömer Sinan Ağacan's avatar
      HscMain: Delete some unused code · 6319a8cf
      Ömer Sinan Ağacan authored
      Reviewers: bgamari, austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1936
      6319a8cf