1. 23 Oct, 2020 2 commits
  2. 21 Oct, 2020 2 commits
  3. 20 Oct, 2020 5 commits
    • Alan Zimmerman's avatar
      API Annotations: Keep track of unicode for linear arrow notation · ea736839
      Alan Zimmerman authored
      The linear arrow can be parsed as `%1 ->` or a direct single token unicode
      Make sure that this distinction is captured in the parsed AST by using
      IsUnicodeSyntax where it appears, and introduce a new API Annotation,
      AnnMult to represent its location when unicode is not used.
      Updated haddock submodule
    • Ben Gamari's avatar
      gitlab-ci: Rename FLAVOUR -> BUILD_FLAVOUR · 59b08a5d
      Ben Gamari authored
      Previously the Hadrian jobs used the `FLAVOUR` environment variable to
      communicate which flavour `ci.sh` should build whereas `make` used
      `BUILD_FLAVOUR`. This caused unnecessary confusion. Consolidate these
    • Alex D's avatar
      Compile modules with `-fobject-code` enabled to byte-code when loaded with `*`... · 58a1ca38
      Alex D authored
      Compile modules with `-fobject-code` enabled to byte-code when loaded with `*` prefix in ghci (#8042)
      The documentation states that when using :add and :load, the `*` prefix forces a module
      to be loaded as byte-code. However, this seems to be ignored when -fobject-code has been
      enabled. In that case, the compiled code is always used, regardless of whether the *-form
      is used.
      The idea is to consult the Targets in HscEnv and check the 'targetAllowObjCode' flag. If
      the flag for given module is set, then patch up DynFlags and select compilation backend
      This would require a linear scan of course, but that shouldn't be too costly.
    • Krzysztof Gogolewski's avatar
      Minor comments, update linear types docs · 6c7a5c0c
      Krzysztof Gogolewski authored
      - Update comments: placeHolderTypeTc no longer exists
        "another level check problem" was a temporary comment from linear types
      - Use Mult type synonym (reported in #18676)
      - Mention multiplicity-polymorphic fields in linear types docs
    • Ben Gamari's avatar
      testsuite: Add test for #18346 · ee5dcdf9
      Ben Gamari authored
      This was fixed by 4291bdda.
  4. 19 Oct, 2020 2 commits
    • Sylvain Henry's avatar
      Remove pdocPrec · 9648d680
      Sylvain Henry authored
      pdocPrec was only used in GHC.Cmm.DebugBlock.pprUnwindExpr, so remove
      it. OutputableP becomes a one-function class which might be better for
    • Vladislav Zavialov's avatar
      Implement -Woperator-whitespace (#18834) · b5b3e34e
      Vladislav Zavialov authored
      This patch implements two related warnings:
            warns on uses of infix operators that would be parsed
            differently were a particular GHC extension enabled
            warns on prefix, suffix, and tight infix uses of infix
      Updates submodules: haddock, containers.
  5. 18 Oct, 2020 8 commits
    • Hécate Moonlight's avatar
      Linting corrections · d858a3ae
      Hécate Moonlight authored
      * Bring back LANGUAGE pragmas in GHC.IO.Handle.Lock.Windows
      * Exclude some modules that are wrongfully reported
    • Sylvain Henry's avatar
      Don't get host RTS ways via settings (#18651) · a91dcb66
      Sylvain Henry authored
      To correctly perform a linking hack for Windows we need to link with the
      RTS GHC is currently using. We used to query the RTS ways via the
      "settings" file but it is fragile (#18651). The hack hasn't been fixed
      to take into account all the ways (Tracing) and it makes linking of GHC
      with another RTS more difficult (we need to link with another RTS and to
      regenerate the settings file).
      So this patch uses the ways reported by the RTS itself
      (GHC.Platform.Ways.hostWays) instead of the "settings" file.
    • Dylan Yudaken's avatar
    • Dylan Yudaken's avatar
      When using rts_setInCallCapability, lock incall threads · 50e9df49
      Dylan Yudaken authored
      This diff makes sure that incall threads, when using `rts_setInCallCapability`, will be created as locked.
      If the thread is not locked, the thread might end up being scheduled to a different capability.
      While this is mentioned in the docs for `rts_setInCallCapability,`, it makes the method significantly less useful as there is no guarantees on the capability being used.
      This commit also adds a test to make sure things stay on the correct capability.
    • Sebastian Graf's avatar
      Testsuite: Add dead arity analysis tests · 451455fd
      Sebastian Graf authored
      We didn't seem to test these old tests at all, judging from their
      expected output.
    • Sebastian Graf's avatar
      Arity: Record arity types for non-recursive lets · 6b3eb06a
      Sebastian Graf authored
      In #18793, we saw a compelling example which requires us to look at
      non-recursive let-bindings during arity analysis and unleash their arity
      types at use sites.
      After the refactoring in the previous patch, the needed change is quite
      simple and very local to `arityType`'s defn for non-recurisve `Let`.
      Apart from that, we had to get rid of the second item of
      `Note [Dealing with bottoms]`, which was entirely a safety measure and
      hindered optimistic fixed-point iteration.
      Fixes #18793.
      The following metric increases are all caused by this commit and a
      result of the fact that we just do more work now:
      Metric Increase:
    • Sebastian Graf's avatar
      Arity: Refactor fixed-point iteration in GHC.Core.Opt.Arity · 7eb46a09
      Sebastian Graf authored
      Arity analysis used to propagate optimistic arity types during
      fixed-point interation through the `ArityEnv`'s `ae_cheap_fun` field,
      which is like `GHC.Core.Utils.exprIsCheap`, but also considers the
      current iteration's optimistic arity, for the binder in question only.
      In #18793, we have seen that this is a problematic design, because it
      doesn't allow us to look through PAP bindings of that binder.
      Hence this patch refactors to a more traditional form with an explicit
      signature environment, in which we record the optimistic `ArityType` of
      the binder in question (and at the moment is the *only* binder that is
      recorded in the arity environment).
    • John Ericson's avatar
      Skip type family defaults with hs-boot and hsig files · 59d7c9f4
      John Ericson authored
      Works around #17190, possible resolution for #17224. New design is is
      according to accepted [GHC Propoal 320].
      Instances in signatures currently unconditionally opt into associated
      family defaults if no explicit instance is given. This is bad for two
        1. It constrains possible instantiations to use the default, rather
        than possibly define the associated family differently.
        2. It breaks compilation as type families are unsupported in
      This PR simply turns off the filling in of defaults in those cases.
      Additionally, it squelches a missing definition warning for hs-boot too
      that was only squelched for hsig before.
      The downsides are:
        1. There is no way to opt into the default, other than copying its
        2. If we fixed type classes in signatures, and wanted instances to
        have to explicitly *out of* rather than into the default, that would
        now be a breaking change.
      The change that is most unambiguously goood is harmonizing the warning
      squelching between hs-boot or hsig. Maybe they should have the warning
      (opt out of default) maybe they shouldn't (opt in to default), but
      surely it should be the same for both.
      Add hs-boot version of a backpack test regarding class-specified
      defaults in instances that appear in an hs-boot file.
      The metrics increase is very slight and makes no sense --- at least no
      one has figured anything out after this languishing for a while, so I'm
      just going to accept it.
      Metric Increase:
      [GHC proposal 320]: https://github.com/ghc-proposals/ghc-proposals/pull/320
  6. 17 Oct, 2020 2 commits
  7. 16 Oct, 2020 13 commits
  8. 15 Oct, 2020 4 commits
  9. 14 Oct, 2020 2 commits
    • Ben Gamari's avatar
      users-guide: Add missing :ghc-flag: directive · 0c4bfed8
      Ben Gamari authored
    • Simon Peyton Jones's avatar
      Fix some missed opportunities for preInlineUnconditionally · 15d2340c
      Simon Peyton Jones authored
      There are two signficant changes here:
      * Ticket #18815 showed that we were missing some opportunities for
        preInlineUnconditionally.  The one-line fix is in the code for
        GHC.Core.Opt.Simplify.Utils.preInlineUnconditionally, which now
        switches off only for INLINE pragmas.  I expanded
        Note [Stable unfoldings and preInlineUnconditionally] to explain.
      * When doing this I discovered a way in which preInlineUnconditionally
        was occasionally /too/ eager.  It's all explained in
        Note [Occurrences in stable unfoldings] in GHC.Core.Opt.OccurAnal,
        and the one-line change adding markAllMany to occAnalUnfolding.
      I also got confused about what NoUserInline meant, so I've renamed
      it to NoUserInlinePrag, and changed its pretty-printing slightly.
      That led to soem error messate wibbling, and touches quite a few
      files, but there is no change in functionality.
      I did a nofib run.  As expected, no significant changes.
              Program           Size    Allocs
               sphere          -0.0%     -0.4%
                  Min          -0.0%     -0.4%
                  Max          -0.0%     +0.0%
       Geometric Mean          -0.0%     -0.0%
      I'm allowing a max-residency increase for T10370, which seems
      very irreproducible. (See comments on !4241.)  There is always
      sampling error for max-residency measurements; and in any case
      the change shows up on some platforms but not others.
      Metric Increase: