[Git][ghc/ghc][ghc-9.4] 11 commits: Ignore .hie-bios

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Sun Oct 16 17:28:06 UTC 2022 


Ben Gamari pushed to branch ghc-9.4 at Glasgow Haskell Compiler / GHC


Commits:
15c496c5 by Sebastian Graf at 2022-10-12T19:20:16-04:00
Ignore .hie-bios

(cherry picked from commit 2563b95cda983cd6be23a5be01fe1f1873f1fa4f)

- - - - -
26af15a0 by Sebastian Graf at 2022-10-12T19:20:16-04:00
CprAnal: Set signatures of DFuns to top

The recursive DFun in the reproducer for #20836 also triggered a bug in CprAnal
that is observable in a debug build. The CPR signature of a recursive DFunId
was never updated and hence the optimistic arity 0 bottom signature triggered a
mismatch with the arity 1 of the binding in WorkWrap. We never miscompiled any
code because WW doesn't exploit bottom CPR signatures.

(cherry picked from commit 94f2e92a2510a3338c5201a4dcc69666fa9575f8)

- - - - -
ecb6accd by Sebastian Graf at 2022-10-14T16:16:07-04:00
CorePrep: Don't speculatively evaluate recursive calls (#20836)

In #20836 we have optimised a terminating program into an endless loop,
because we speculated the self-recursive call of a recursive DFun.
Now we track the set of enclosing recursive binders in CorePrep to prevent
speculation of such self-recursive calls.

See the updates to Note [Speculative evaluation] for details.

Fixes #20836.

(cherry picked from commit b570da84b7aad5ca3f90f2d1c1a690c927e99fe9)

- - - - -
c0b5736c by Sebastian Graf at 2022-10-14T17:10:27-04:00
Simplify: Take care with eta reduction in recursive RHSs (#21652)

Similar to the fix to #20836 in CorePrep, we now track the set of enclosing
recursive binders in the SimplEnv and SimpleOptEnv.
See Note [Eta reduction in recursive RHSs] for details.

I also updated Note [Arity robustness] with the insights Simon and I had in a
call discussing the issue.

Fixes #21652.

Unfortunately, we get a 5% ghc/alloc regression in T16577. That is due to
additional eta reduction in GHC.Read.choose1 and the resulting ANF-isation
of a large list literal at the top-level that didn't happen before (presumably
because it was too interesting to float to the top-level). There's not much we
can do about that.

Metric Increase:
    T16577

(cherry picked from commit 49fb2f9b16ca987648d2ac57eecf1892d49852ec)

- - - - -
ccdaa83c by Ben Gamari at 2022-10-14T17:10:27-04:00
CmmToLlvm: Don't aliasify builtin LLVM variables

Our aliasification logic would previously turn builtin LLVM variables
into aliases, which apparently confuses LLVM. This manifested in
initializers failing to be emitted, resulting in many profiling failures
with the LLVM backend.

Fixes #22019.

(cherry picked from commit cd6f5bfd0cc2bcf74de1d9edb43fe4b338b4c4e3)

- - - - -
671491cc by Matthew Pickering at 2022-10-14T17:10:27-04:00
haddock docs: Fix links from identifiers to dependent packages

When implementing the base_url changes I made the pretty bad mistake of
zipping together two lists which were in different orders. The simpler
thing to do is just modify `haddockDependencies` to also return the
package identifier so that everything stays in sync.

Fixes #22001

(cherry picked from commit 2361b3bc08811b0d2fb8f8fc5635b7c2fec157c6)

- - - - -
6bf992e6 by Ryan Scott at 2022-10-14T17:10:27-04:00
DeriveFunctor: Check for last type variables using dataConUnivTyVars

Previously, derived instances of `Functor` (as well as the related classes
`Foldable`, `Traversable`, and `Generic1`) would determine which constraints to
infer by checking for fields that contain the last type variable. The problem
was that this last type variable was taken from `tyConTyVars`. For GADTs, the
type variables in each data constructor are _not_ the same type variables as
in `tyConTyVars`, leading to #22167.

This fixes the issue by instead checking for the last type variable using
`dataConUnivTyVars`. (This is very similar in spirit to the fix for #21185,
which also replaced an errant use of `tyConTyVars` with type variables from
each data constructor.)

Fixes #22167.

(cherry picked from commit 8a666ad2a89a8ad2aa24a6406b88f516afaec671)

- - - - -
3eace272 by Ryan Scott at 2022-10-14T17:10:27-04:00
Windows: Always define _UCRT when compiling C code

As seen in #22159, this is required to ensure correct behavior when MinGW-w64
headers are in the `C_INCLUDE_PATH`.

Fixes #22159.

(cherry picked from commit 3a815f30bcba5672085e823aeef90863253b0b1a)

- - - - -
9ae4865b by Cheng Shao at 2022-10-14T17:10:27-04:00
rts: fix missing dirty_MVAR argument in stg_writeIOPortzh

(cherry picked from commit ee471dfb8a4a4bb5131a5baa61d1d0d22c933d5f)

- - - - -
6af677a9 by Matthew Pickering at 2022-10-14T17:10:27-04:00
Don't include BufPos in interface files

Ticket #22162 pointed out that the build directory was leaking into the
ABI hash of a module because the BufPos depended on the location of the
build tree.

BufPos is only used in GHC.Parser.PostProcess.Haddock, and the
information doesn't need to be propagated outside the context of a
module.

Fixes #22162

(cherry picked from commit 7f0decd5063a853fc8f38a8944b2c91995cd5e48)

- - - - -
9a12e496 by Ben Gamari at 2022-10-16T10:41:41-04:00
gitlab-ci: Ensure that ghc derivation is in scope

Previously the lint-ci job attempted to use cabal-install (specifically
`cabal update`) without a GHC in PATH. However, cabal-install-3.8
appears to want GHC, even for `cabal update`.

(cherry picked from commit 25f68acedf822e9ea21d1659b1f897fcfc96e5d4)

- - - - -


30 changed files:

- .gitignore
- .gitlab-ci.yml
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Data/Graph/UnVar.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Tc/Deriv/Functor.hs
- compiler/GHC/Tc/Deriv/Generics.hs
- compiler/GHC/Tc/Deriv/Infer.hs
- compiler/GHC/Types/SrcLoc.hs
- compiler/GHC/Utils/Binary.hs
- hadrian/src/Rules/Documentation.hs
- hadrian/src/Settings/Builders/Haddock.hs
- m4/fp_setup_windows_toolchain.m4
- rts/PrimOps.cmm
- testsuite/tests/arityanal/should_compile/Arity03.stderr
- + testsuite/tests/arityanal/should_run/Makefile
- + testsuite/tests/arityanal/should_run/T21652.hs
- + testsuite/tests/arityanal/should_run/T21652.stdout
- + testsuite/tests/arityanal/should_run/all.T
- testsuite/tests/count-deps/CountDepsAst.stdout
- testsuite/tests/count-deps/CountDepsParser.stdout
- testsuite/tests/deSugar/should_compile/T19969.stderr


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2cf828e829011f103ea946756a0c53322fa238dd...9a12e4961256f4c25201b8b8736ab4ef4ba0083e

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2cf828e829011f103ea946756a0c53322fa238dd...9a12e4961256f4c25201b8b8736ab4ef4ba0083e
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20221016/94b6dcb8/attachment.html>

More information about the ghc-commits mailing list