[Git][ghc/ghc][wip/T17910] 13 commits: JS: Improve compatibility with recent emsdk

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Wed Aug 9 16:43:04 UTC 2023



Simon Peyton Jones pushed to branch wip/T17910 at Glasgow Haskell Compiler / GHC


Commits:
aa07402e by Luite Stegeman at 2023-08-05T23:15:55+09:00
JS: Improve compatibility with recent emsdk

The JavaScript code in libraries/base/jsbits/base.js had some
hardcoded offsets for fields in structs, because we expected
the layout of the data structures to remain unchanged. Emsdk
3.1.42 changed the layout of the stat struct, breaking this
assumption, and causing code in .hsc files accessing the
stat struct to fail.

This patch improves compatibility with recent emsdk by
removing the assumption that data layouts stay unchanged:

    1. offsets of fields in structs used by JavaScript code are
       now computed by the configure script, so both the .js and
       .hsc files will automatically use the new layout if anything
       changes.
    2. the distrib/configure script checks that the emsdk version
       on a user's system is the same version that a bindist was
       booted with, to avoid data layout inconsistencies

See #23641

- - - - -
b938950d by Luite Stegeman at 2023-08-07T06:27:51-04:00
JS: Fix missing local variable declarations

This fixes some missing local variable declarations that were
found by running the testsuite in strict mode.

Fixes #23775

- - - - -
6c0e2247 by sheaf at 2023-08-07T13:31:21-04:00
Update Haddock submodule to fix #23368

This submodule update adds the following three commits:

bbf1c8ae - Check for puns
0550694e - Remove fake exports for (~), List, and Tuple<n>
5877bceb - Fix pretty-printing of Solo and MkSolo

These commits fix the issues with Haddock HTML rendering reported in
ticket #23368.

Fixes #23368

- - - - -
5b5be3ea by Matthew Pickering at 2023-08-07T13:32:00-04:00
Revert "Bump bytestring submodule to 0.11.5.1"

This reverts commit 43578d60bfc478e7277dcd892463cec305400025.

Fixes #23789

- - - - -
01961be3 by Ben Gamari at 2023-08-08T02:47:14-04:00
configure: Derive library version from ghc-prim.cabal.in

Since ghc-prim.cabal is now generated by Hadrian, we cannot depend upon
it.

Closes #23726.

- - - - -
3b373838 by Ryan Scott at 2023-08-08T02:47:49-04:00
tcExpr: Push expected types for untyped TH splices inwards

In !10911, I deleted a `tcExpr` case for `HsUntypedSplice` in favor of a much
simpler case that simply delegates to `tcApp`. Although this passed the test
suite at the time, this was actually an error, as the previous `tcExpr` case
was critically pushing the expected type inwards. This actually matters for
programs like the one in #23796, which GHC would not accept with type inference
alone—we need full-blown type _checking_ to accept these.

I have added back the previous `tcExpr` case for `HsUntypedSplice` and now
explain why we have two different `HsUntypedSplice` cases (one in `tcExpr` and
another in `splitHsApps`) in `Note [Looking through Template Haskell splices in
splitHsApps]` in `GHC.Tc.Gen.Head`.

Fixes #23796.

- - - - -
0ef1d8ae by sheaf at 2023-08-08T21:26:51-04:00
Compute all emitted diagnostic codes

This commit introduces in GHC.Types.Error.Codes the function

  constructorCodes :: forall diag. (...) => Map DiagnosticCode String

which computes a collection of all the diagnostic codes that correspond
to a particular type. In particular, we can compute the collection of
all diagnostic codes emitted by GHC using the invocation

  constructorCodes @GhcMessage

We then make use of this functionality in the new "codes" test which
checks consistency and coverage of GHC diagnostic codes.
It performs three checks:

  - check 1: all non-outdated GhcDiagnosticCode equations
    are statically used.
  - check 2: all outdated GhcDiagnosticCode equations
    are statically unused.
  - check 3: all statically used diagnostic codes are covered by
    the testsuite (modulo accepted exceptions).

- - - - -
4bc7b1e5 by Fraser Tweedale at 2023-08-08T21:27:32-04:00
numberToRangedRational: fix edge cases for exp ≈ (maxBound :: Int)

Currently a negative exponent less than `minBound :: Int` results in
Infinity, which is very surprising and obviously wrong.

```
λ> read "1e-9223372036854775808" :: Double
0.0
λ> read "1e-9223372036854775809" :: Double
Infinity
```

There is a further edge case where the exponent can overflow when
increased by the number of tens places in the integer part, or
underflow when decreased by the number of leading zeros in the
fractional part if the integer part is zero:

```
λ> read "10e9223372036854775807" :: Double
0.0
λ> read "0.01e-9223372036854775808" :: Double
Infinity
```

To resolve both of these issues, perform all arithmetic and
comparisons involving the exponent in type `Integer`.  This approach
also eliminates the need to explicitly check the exponent against
`maxBound :: Int` and `minBound :: Int`, because the allowed range
of the exponent (i.e. the result of `floatRange` for the target
floating point type) is certainly within those bounds.

This change implements CLC proposal 192:
https://github.com/haskell/core-libraries-committee/issues/192

- - - - -
6eab07b2 by Alan Zimmerman at 2023-08-08T21:28:10-04:00
EPA: Remove Location from WarningTxt source

This is not needed.

- - - - -
ae85710d by Simon Peyton Jones at 2023-08-09T10:38:00+01:00
Be more careful about inlining top-level used-once things

Addresses #17910

- - - - -
fe3825f0 by Simon Peyton Jones at 2023-08-09T10:38:00+01:00
Work in progress...

- - - - -
5285a263 by Simon Peyton Jones at 2023-08-09T10:38:00+01:00
Fix for #23813

Zap one-shot info when floating a join point to top level

- - - - -
bc26fb6d by Simon Peyton Jones at 2023-08-09T17:41:38+01:00
Subtle occurrence analyser point

(make sure this is documented properly before landing all this)

- - - - -


30 changed files:

- .gitlab-ci.yml
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/HsToCore/Errors/Ppr.hs
- compiler/GHC/Iface/Errors/Ppr.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/JS/Make.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Errors/Ppr.hs
- compiler/GHC/StgToJS/Expr.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Head.hs
- compiler/GHC/Types/Error.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Unit/Module/Warnings.hs
- compiler/GHC/Utils/Binary.hs
- configure.ac
- distrib/configure.ac.in
- hadrian/src/Packages.hs
- hadrian/src/Rules/Test.hs
- hadrian/src/Settings/Default.hs
- hadrian/src/Settings/Warnings.hs
- libraries/base/System/Posix/Internals.hs
- libraries/base/Text/Read/Lex.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d41b60cc2b3a9404503a4acc7e26a46a69a7a5dd...bc26fb6d52a1e60a9374e21265042605b8a0f104

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d41b60cc2b3a9404503a4acc7e26a46a69a7a5dd...bc26fb6d52a1e60a9374e21265042605b8a0f104
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/20230809/7e8783d0/attachment-0001.html>


More information about the ghc-commits mailing list