[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 8 commits: Allow imports to reference multiple fields with the same name (#21625)

Tue Sep 13 09:27:28 UTC 2022

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC

Commits:
cae325b7 by Adam Gundry at 2022-09-13T05:27:15-04:00
Allow imports to reference multiple fields with the same name (#21625)

If a module `M` exports two fields `f` (using DuplicateRecordFields), we can
still accept

    import M (f)
    import M hiding (f)

and treat `f` as referencing both of them.  This was accepted in GHC 9.0, but gave
rise to an ambiguity error in GHC 9.2.  See #21625.

This patch also documents this behaviour in the user's guide, and updates the
test for #16745 which is now treated differently.

- - - - -
7f31358c by Matthew Pickering at 2022-09-13T05:27:16-04:00
hadrian: Use a stamp file to record when a package is built in a certain way

Before this patch which library ways we had built wasn't recorded
directly. So you would run into issues if you build the .conf file with
some library ways before switching the library ways which you wanted to
build.

Now there is one stamp file for each way, so in order to build a
specific way you can need that specific stamp file rather than going
indirectly via the .conf file.

- - - - -
232fe1c5 by Matthew Pickering at 2022-09-13T05:27:16-04:00
hadrian: Inplace/Final package databases

There are now two different package databases per stage. An inplace
package database contains .conf files which point directly into the
build directories. The final package database contains .conf files which
point into the installed locations. The inplace .conf files are created
before any building happens and have fake ABI hash values. The final
.conf files are created after a package finished building and contains
the proper ABI has.

The motivation for this is to make the dependency structure more
fine-grained when building modules. Now a module depends just depends
directly on M.o from package p rather than the .conf file depend on the
.conf file for package p. So when all of a modules direct dependencies
have finished building we can start building it rather than waiting for
the whole package to finish.

The secondary motivation is that the multi-repl doesn't need to build
everything before starting the multi-repl session. We can just configure
the inplace package-db and use that in order to start the repl.

- - - - -
79dd0b94 by Matthew Pickering at 2022-09-13T05:27:16-04:00
hadrian: Add some more packages to multi-cradle

The main improvement here is to pass `-this-unit-id` for executables so
that they can be added to the multi-cradle if desired as well as normal
library packages.

- - - - -
296be313 by Matthew Pickering at 2022-09-13T05:27:16-04:00
hadrian: Need builders needed by Cabal Configure in parallel

Because of the use of withStaged (which needs the necessary builder)
when configuring a package, the builds of stage1:exe:ghc-bin and
stage1:exe:ghc-pkg where being linearised when building a specific
target like `binary-dist-dir`.

Thankfully the fix is quite local, to supply all the `withStaged`
arguments together so the needs can be batched together and hence
performed in parallel.

Fixes #22093

- - - - -
9e354152 by Matthew Pickering at 2022-09-13T05:27:16-04:00
Remove stage1:exe:ghc-bin pre-build from CI script

CI builds stage1:exe:ghc-bin before the binary-dist target which
introduces some quite bad linearisation (see #22093) because we don't
build stage1 compiler in parallel with anything. Then when the
binary-dist target is started we have to build stage1:exe:ghc-pkg before
doing anything.

Fixes #22094

- - - - -
2f8257fa by Cheng Shao at 2022-09-13T05:27:18-04:00
ci: remove unused appveyor config

- - - - -
12b37549 by Cheng Shao at 2022-09-13T05:27:19-04:00
compiler: remove unused lazy state monad

- - - - -

30 changed files:

- − .appveyor.sh
- .gitlab/ci.sh
- − appveyor.yml
- compiler/GHC/Rename/Names.hs
- − compiler/GHC/Utils/Monad/State/Lazy.hs
- compiler/ghc.cabal.in
- docs/users_guide/exts/duplicate_record_fields.rst
- hadrian/hadrian.cabal
- hadrian/src/Base.hs
- hadrian/src/Builder.hs
- hadrian/src/Context.hs
- hadrian/src/Context/Type.hs
- hadrian/src/Hadrian/Builder.hs
- hadrian/src/Hadrian/Haskell/Cabal/Parse.hs
- hadrian/src/Packages.hs
- hadrian/src/Rules.hs
- hadrian/src/Rules/BinaryDist.hs
- hadrian/src/Rules/Compile.hs
- hadrian/src/Rules/Dependencies.hs
- hadrian/src/Rules/Documentation.hs
- hadrian/src/Rules/Generate.hs
- hadrian/src/Rules/Libffi.hs
- hadrian/src/Rules/Library.hs
- hadrian/src/Rules/Nofib.hs
- hadrian/src/Rules/Program.hs
- hadrian/src/Rules/Register.hs
- hadrian/src/Rules/Rts.hs
- hadrian/src/Rules/SourceDist.hs
- hadrian/src/Rules/Test.hs
- hadrian/src/Rules/ToolArgs.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cc1baeb905caf7011d50dd959e9d3f65f6e9fb82...12b37549763de33b84ef30a8b116d2ff32a5743f

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cc1baeb905caf7011d50dd959e9d3f65f6e9fb82...12b37549763de33b84ef30a8b116d2ff32a5743f
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/20220913/fa1f8229/attachment-0001.html>