[Git][ghc/ghc][ghc-9.10] 12 commits: Revert "Apply shellcheck suggestion to SUBST_TOOLDIR"
Ben Gamari (@bgamari)
gitlab at gitlab.haskell.org
Wed Mar 27 03:40:58 UTC 2024
Ben Gamari pushed to branch ghc-9.10 at Glasgow Haskell Compiler / GHC
Commits:
b09cbad8 by Zubin Duggal at 2024-03-25T12:21:37-04:00
Revert "Apply shellcheck suggestion to SUBST_TOOLDIR"
This reverts commit c82770f57977a2b5add6e1378f234f8dd6153392.
The shellcheck suggestion is spurious and results in SUBST_TOOLDIR being a
no-op. `set` sets positional arguments for bash, but we want to set the variable
given as the first autoconf argument.
Fixes #24542
Metric decreases because the paths in the settings file are now shorter,
so we allocate less when we read the settings file.
-------------------------
Metric Decrease:
T12425
T13035
T9198
-------------------------
(cherry picked from commit 576f8b7ec292382aaa47fceab504b5abf4cc1f8a)
- - - - -
0d4ee209 by Andrei Borzenkov at 2024-03-25T12:27:07-04:00
Fix compiler crash caused by implicit RHS quantification in type synonyms (#24470)
(cherry picked from commit 7ea971d314c4eba59e12e94bf3eb8edb95fbfac5)
- - - - -
688cb2ff by Cheng Shao at 2024-03-25T12:28:00-04:00
Revert "compiler: make genSym use C-based atomic increment on non-JS 32-bit platforms"
This reverts commit 615eb855416ce536e02ed935ecc5a6f25519ae16. It was
originally intended to fix #24449, but it was merely sweeping the bug
under the rug. 3836a110577b5c9343915fd96c1b2c64217e0082 has properly
fixed the fragile test, and we no longer need the C version of genSym.
Furthermore, the C implementation causes trouble when compiling with
clang that targets i386 due to alignment warning and libatomic linking
issue, so it makes sense to revert it.
(cherry picked from commit 39f3ac3e1b47e9fdac8fcf2d1edcc300a37deb82)
- - - - -
c5c19c14 by Cheng Shao at 2024-03-25T12:28:01-04:00
compiler: fix out-of-bound memory access of genSym on 32-bit
This commit fixes an unnoticed out-of-bound memory access of genSym on
32-bit. ghc_unique_inc is 32-bit sized/aligned on 32-bit platforms,
but we mistakenly treat it as a Word64 pointer in genSym, and
therefore will accidentally load 2 garbage higher bytes, or with a
small but non-zero chance, overwrite something else in the data
section depends on how the linker places the data segments. This
regression was introduced in !11802 and fixed here.
(cherry picked from commit e6bfb85c842edca36754bb8914e725fbaa1a83a6)
- - - - -
67defa84 by Alan Zimmerman at 2024-03-25T12:28:15-04:00
EPA: Fix regression discarding comments in contexts
Closes #24533
(cherry picked from commit 7da7f8f643f1bfc4aa034a731f2f85cda007b286)
- - - - -
97afcca5 by Alan Zimmerman at 2024-03-25T12:28:31-04:00
EPA: Address more 9.10.1-alpha1 regressions from recent changes
Closes #24533
Hopefully for good this time
(cherry picked from commit bd8209eb8e447a5ae1d736f034f4a3986e0727f7)
- - - - -
850fc30e by Alan Zimmerman at 2024-03-25T12:28:48-04:00
EPA: Clean up Exactprint helper functions a bit
- Introduce a helper lens to compose on `EpAnn a` vs `a` versions
- Rename some prime versions of functions back to non-prime
They were renamed during the rework
(cherry picked from commit 5f27517687c711593a23f1c9e5bd09ad9ec22fa4)
- - - - -
01a6a717 by Vladislav Zavialov at 2024-03-25T12:29:02-04:00
Type operators in promoteOccName (#24570)
Type operators differ from term operators in that they are lexically
classified as (type) constructors, not as (type) variables.
Prior to this change, promoteOccName did not account for this
difference, causing a scoping issue that affected RequiredTypeArguments.
type (!@#) = Bool
f = idee (!@#) -- Not in scope: ‘!@#’ (BUG)
Now we have a special case in promoteOccName to account for this.
(cherry picked from commit da2a10ceab7498fbbd5723dee0393ce75f2bb562)
- - - - -
e5b111e9 by Simon Peyton Jones at 2024-03-25T12:29:15-04:00
Expand untyped splices in tcPolyExprCheck
Fixes #24559
(cherry picked from commit 97a2bb1cdfa4b244a58374658aec6d48ce23a54a)
- - - - -
222a5240 by Andrei Borzenkov at 2024-03-25T12:29:27-04:00
Fix TH handling in `pat_to_type_pat` function (#24571)
There was missing case for `SplicePat` in `pat_to_type_at` function,
hence patterns with splicing that checked against `forall->` doesn't work
properly because they fall into the "illegal pattern" case.
Code example that is now accepted:
g :: forall a -> ()
g $([p| a |]) = ()
(cherry picked from commit 6fafc51e9206abd62881131c282ec3b9e1584c5b)
- - - - -
c394cfa7 by Ben Gamari at 2024-03-26T13:46:41-04:00
Bump haddock submodule
Fixes #24485 by fixing the default hyperlinked sources URL pattern.
- - - - -
337a5073 by Ben Gamari at 2024-03-26T19:53:32-04:00
Add build ordering edge for GHC.IO.Encoding.Iconv
- - - - -
30 changed files:
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Head.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Gen/Pat.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/Gen/Splice.hs-boot
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/Name/Occurrence.hs
- compiler/GHC/Types/Unique/Supply.hs
- compiler/cbits/genSym.c
- libraries/base/src/GHC/IO/Encoding/Iconv.hs
- m4/fp_settings.m4
- testsuite/tests/parser/should_compile/DumpSemis.stderr
- testsuite/tests/printer/Makefile
- + testsuite/tests/printer/Test24533.hs
- + testsuite/tests/printer/Test24533.stdout
- testsuite/tests/printer/all.T
- + testsuite/tests/th/T24559.hs
- + testsuite/tests/th/T24571.hs
- testsuite/tests/th/all.T
- + testsuite/tests/typecheck/should_compile/T24470b.hs
- testsuite/tests/typecheck/should_compile/all.T
- + testsuite/tests/typecheck/should_fail/T24470a.hs
- + testsuite/tests/typecheck/should_fail/T24470a.stderr
- testsuite/tests/typecheck/should_fail/all.T
- + testsuite/tests/vdq-rta/should_compile/T24570.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cf814fe982f42483c672802ce905350d99a85a35...337a5073e23fcb82e6b341ce083708e736c9ea89
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cf814fe982f42483c672802ce905350d99a85a35...337a5073e23fcb82e6b341ce083708e736c9ea89
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/20240326/3ba30ead/attachment-0001.html>
More information about the ghc-commits
mailing list