[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