[Git][ghc/ghc][wip/T15808] 5 commits: Check for large tuples more thoroughly

Ben Gamari gitlab at gitlab.haskell.org
Fri Oct 30 14:45:40 UTC 2020



Ben Gamari pushed to branch wip/T15808 at Glasgow Haskell Compiler / GHC


Commits:
2ef2fac4 by Ryan Scott at 2020-10-29T04:18:52-04:00
Check for large tuples more thoroughly

This fixes #18723 by:

* Moving the existing `GHC.Tc.Gen.HsType.bigConstraintTuple` validity
  check to `GHC.Rename.Utils.checkCTupSize` for consistency with
  `GHC.Rename.Utils.checkTupSize`, and
* Using `check(C)TupSize` when checking tuple _types_, in addition
  to checking names, expressions, and patterns.

Note that I put as many of these checks as possible in the typechecker so
that GHC can properly distinguish between boxed and constraint tuples. The
exception to this rule is checking names, which I perform in the renamer
(in `GHC.Rename.Env`) so that we can rule out `(,, ... ,,)` and
`''(,, ... ,,)` alike in one fell swoop.

While I was in town, I also removed the `HsConstraintTuple` and
`HsBoxedTuple` constructors of `HsTupleSort`, which are functionally
unused. This requires a `haddock` submodule bump.

- - - - -
7f8be3eb by Richard Eisenberg at 2020-10-29T22:08:13-04:00
Remove unnecessary gender from comments/docs

While, say, alternating "he" and "she" in sequential writing
may be nicer than always using "they", reading code/documentation
is almost never sequential. If this small change makes individuals
feel more welcome in GHC's codebase, that's a good thing.

- - - - -
ed3b3da3 by Ben Gamari at 2020-10-30T10:21:02-04:00
rts/linker: Fix relocation overflow in PE linker

Previously the overflow check for the IMAGE_REL_AMD64_ADDR32NB
relocation failed to account for the signed nature of the value.
Specifically, the overflow check was:

    uint64_t v;
    v = S + A;
    if (v >> 32) { ... }

However, `v` ultimately needs to fit into 32-bits as a signed value.
Consequently, values `v > 2^31` in fact overflow yet this is not caught
by the existing overflow check.

Here we rewrite the overflow check to rather ensure that
`INT32_MIN <= v <= INT32_MAX`. There is now quite a bit of repetition
between the `IMAGE_REL_AMD64_REL32` and `IMAGE_REL_AMD64_ADDR32` cases
but I am leaving fixing this for future work.

This bug was first noticed by @awson.

Fixes #15808.

- - - - -
b9b16c94 by Ben Gamari at 2020-10-30T10:21:20-04:00
rts/linker: Fold IMAGE_REL_AMD64_REL32 case into IMAGE_REL_AMD64_ADDR32

After fixing #15808 these cases are all essentially equivalent.  Avoids
some repetition and hopefully eliminates the potential for divergence in
the future.

- - - - -
42492e4a by Ben Gamari at 2020-10-30T10:45:14-04:00
rts/linker: Try using m32 to allocate PE symbol extras

- - - - -


30 changed files:

- compiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/HsToCore/Pmc/Solver/Types.hs
- compiler/GHC/HsToCore/Utils.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/Rename/Utils.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Gen/Pat.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/Solver/Interact.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Types/Basic.hs
- compiler/GHC/Types/Name/Reader.hs
- compiler/GHC/Utils/Outputable.hs
- docs/users_guide/exts/partial_type_signatures.rst
- rts/Linker.c
- rts/linker/PEi386.c
- − testsuite/tests/rename/should_fail/T6148.stderr
- + testsuite/tests/rename/should_fail/T6148a.hs
- + testsuite/tests/rename/should_fail/T6148a.stderr
- + testsuite/tests/rename/should_fail/T6148b.hs
- + testsuite/tests/rename/should_fail/T6148b.stderr
- testsuite/tests/rename/should_fail/T6148.hs → testsuite/tests/rename/should_fail/T6148c.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c798a168cffa45d3edc71f9c69de70053d6290c2...42492e4a73b85ba1a5aea9af78eba42bd25699ff

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c798a168cffa45d3edc71f9c69de70053d6290c2...42492e4a73b85ba1a5aea9af78eba42bd25699ff
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/20201030/ccb18775/attachment.html>


More information about the ghc-commits mailing list