[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 6 commits: compiler: re-engineer the treatment of rebindable if

Tue Jul 14 12:10:13 UTC 2020

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

Commits:
e8e75736 by Alp Mestanogullari at 2020-07-14T08:10:02-04:00
compiler: re-engineer the treatment of rebindable if

Executing on the plan described in #17582, this patch changes the way if expressions
are handled in the compiler in the presence of rebindable syntax. We get rid of the
SyntaxExpr field of HsIf and instead, when rebindable syntax is on, we rewrite the HsIf
node to the appropriate sequence of applications of the local `ifThenElse` function.

In order to be able to report good error messages, with expressions as they were
written by the user (and not as desugared by the renamer), we make use of TTG
extensions to extend GhcRn expression ASTs with an `HsExpansion` construct, which
keeps track of a source (GhcPs) expression and the desugared (GhcRn) expression that
it gives rise to. This way, we can typecheck the latter while reporting the former in
error messages.

In order to discard the error context lines that arise from typechecking the desugared
expressions (because they talk about expressions that the user has not written), we
carefully give a special treatment to the nodes fabricated by this new renaming-time
transformation when typechecking them. See Note [Rebindable syntax and HsExpansion]
for more details. The note also includes a recipe to apply the same treatment to
other rebindable constructs.

Tests 'rebindable11' and 'rebindable12' have been added to make sure we report
identical error messages as before this patch under various circumstances.

We also now disable rebindable syntax when processing untyped TH quotes, as per
the discussion in #18102 and document the interaction of rebindable syntax and
Template Haskell, both in Note [Template Haskell quotes and Rebindable Syntax]
and in the user guide, adding a test to make sure that we do not regress in
that regard.

- - - - -
0c79634a by Sergei Trofimovich at 2020-07-14T08:10:04-04:00
.gitlab: re-enable integer-simple substitute (BIGNUM_BACKEND)

Recently build system migrated from INTEGER_LIBRARY to BIGNUM_BACKEND.
But gitlab CI was never updated. Let's enable BIGNUM_BACKEND=native.

Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/18437
Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>

- - - - -
0de16132 by Sergei Trofimovich at 2020-07-14T08:10:04-04:00
ghc-bignum: bring in sync .hs-boot files with module declarations

Before this change `BIGNUM_BACKEND=native` build was failing as:

```
libraries/ghc-bignum/src/GHC/Num/BigNat/Native.hs:708:16: error:
    * Variable not in scope: naturalFromBigNat# :: WordArray# -> t
    * Perhaps you meant one of these:
        `naturalFromBigNat' (imported from GHC.Num.Natural),
        `naturalToBigNat' (imported from GHC.Num.Natural)
    |
708 |           m' = naturalFromBigNat# m
    |
```

This happens because `.hs-boot` files are slightly out of date.
This change brings in data and function types in sync.

Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/18437
Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>

- - - - -
7b8595ff by Stefan Schulze Frielinghaus at 2020-07-14T08:10:09-04:00
rts/Disassembler.c: Use FMT_HexWord for printing values in hex format

- - - - -
bb30d9ce by Matthias Andreas Benkard at 2020-07-14T08:10:10-04:00
macOS: Load frameworks without stating them first.

macOS Big Sur makes the following change to how frameworks are shipped
with the OS:

> New in macOS Big Sur 11 beta, the system ships with a built-in
> dynamic linker cache of all system-provided libraries. As part of
> this change, copies of dynamic libraries are no longer present on
> the filesystem. Code that attempts to check for dynamic library
> presence by looking for a file at a path or enumerating a directory
> will fail. Instead, check for library presence by attempting to
> dlopen() the path, which will correctly check for the library in the
> cache. (62986286)

https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes/

Therefore, the previous method of checking whether a library exists
before attempting to load it makes GHC.Runtime.Linker.loadFramework
fail to find frameworks installed at /System/Library/Frameworks.

GHC.Runtime.Linker.loadFramework now opportunistically loads the
framework libraries without checking for their existence first,
failing only if all attempts to load a given framework from any of the
various possible locations fail.

- - - - -
a2489006 by Matthias Andreas Benkard at 2020-07-14T08:10:10-04:00
loadFramework: Output the errors collected in all loading attempts.

With the recent change away from first finding and then loading a
framework, loadFramework had no way of communicating the real reason
why loadDLL failed if it was any reason other than the framework
missing from the file system.  It now collects all loading attempt
errors into a list and concatenates them into a string to return to
the caller.

- - - - -

30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- + compiler/GHC/Builtin/RebindableNames.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Coverage.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Match.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Splice.hs
- compiler/GHC/Runtime/Linker.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Types.hs
- compiler/GHC/Tc/Types/Origin.hs
- compiler/GHC/Tc/Utils/Monad.hs
- compiler/GHC/Tc/Utils/Zonk.hs
- compiler/GHC/Types/SrcLoc.hs
- compiler/GHC/Utils/Binary.hs
- compiler/ghc.cabal.in
- docs/users_guide/exts/template_haskell.rst
- ghc/GHCi/UI.hs
- ghc/GHCi/UI/Info.hs
- includes/stg/Types.h
- libraries/ghc-bignum/src/GHC/Num/BigNat.hs-boot
- libraries/ghc-bignum/src/GHC/Num/Natural.hs-boot
- rts/Disassembler.c

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/acdbc05125c70aed67599704b1ac33ddb21ba69f...a2489006dac3b2181fb5e046cad6741575f38c2e

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/acdbc05125c70aed67599704b1ac33ddb21ba69f...a2489006dac3b2181fb5e046cad6741575f38c2e
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/20200714/ccd38342/attachment.html>