[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 4 commits: Bump bytestring submodule to something closer to 0.12.1

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Sun Feb 4 06:34:38 UTC 2024



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


Commits:
27020458 by Matthew Craven at 2024-02-03T01:53:26-05:00
Bump bytestring submodule to something closer to 0.12.1

...mostly so that 16d6b7e835ffdcf9b894e79f933dd52348dedd0c
(which reworks unaligned writes in Builder) and the stuff in
https://github.com/haskell/bytestring/pull/631 can see wider testing.

The less-terrible code for unaligned writes used in Builder on
hosts not known to be ulaigned-friendly also takes less effort
for GHC to compile, resulting in a metric decrease for T21839c
on some platforms.

The metric increase on T21839r is caused by the unrelated commit
750dac33465e7b59100698a330b44de7049a345c.  It perhaps warrants
further analysis and discussion (see #23822) but is not critical.

Metric Decrease:
T21839c
Metric Increase:
T21839r

- - - - -
cdddeb0f by Rodrigo Mesquita at 2024-02-03T01:54:02-05:00
Work around autotools setting C11 standard in CC/CXX

In autoconf >=2.70, C11 is set by default for $CC and $CXX via the
-std=...11 flag. In this patch, we split the "-std" flag out of the $CC
and $CXX variables, which we traditionally assume to be just the
executable name/path, and move it to $CFLAGS/$CXXFLAGS instead.

Fixes #24324

- - - - -
5ff7cc26 by Apoorv Ingle at 2024-02-03T13:14:46-06:00
Expand `do` blocks right before typechecking using the `HsExpansion` philosophy.

- Fixes #18324 #20020 #23147 #22788 #15598 #22086 #21206

- The change is detailed in
  - Note [Expanding HsDo with HsExpansion] in `GHC.Tc.Gen.Do`
  - Note [Doing HsExpansion in the Renamer vs Typechecker] in `GHC.Rename.Expr`
         expains the rational of doing expansions in type checker as opposed to in the renamer

- Adds new datatypes:
  - `GHC.Hs.Expr.XXExprGhcRn`: new datatype makes this expansion work easier
    1. Expansion bits for Expressions, Statements and Patterns in (`ExpandedThingRn`)
    2. `PopErrCtxt` a special GhcRn Phase only artifcat to pop the previous error message in the error context stack

  - `GHC.Basic.Origin` now tracks the reason for expansion in case of Generated
    This is useful for type checking cf. `GHC.Tc.Gen.Expr.tcExpr` case for `HsLam`

  - Kills `HsExpansion` and `HsExpanded` as we have inlined them in `XXExprGhcRn` and `XXExprGhcTc`

- Ensures warnings such as
  1. Pattern match checks
  2. Failable patterns
  3. non-() return in body statements are preserved

- Kill `HsMatchCtxt` in favor of `TcMatchAltChecker`

- Testcases:
  * T18324 T20020 T23147 T22788 T15598 T22086
  * T23147b (error message check),
  * DoubleMatch (match inside a match for pmc check)
  * pattern-fails (check pattern match with non-refutable pattern, eg. newtype)
  * Simple-rec (rec statements inside do statment)
  * T22788 (code snippet from #22788)
  * DoExpanion1 (Error messages for body statments)
  * DoExpansion2 (Error messages for bind statements)
  * DoExpansion3 (Error messages for let statements)

Also repoint haddock to the right submodule so that the test (haddockHypsrcTest) pass

Metric Increase 'compile_time/bytes allocated':
    T9020

The testcase is a pathalogical example of a `do`-block with many statements that do nothing.
Given that we are expanding the statements into function binds, we will have to bear
a (small) 2% cost upfront in the compiler to unroll the statements.

- - - - -
8811b804 by Vladislav Zavialov at 2024-02-04T01:34:33-05:00
Reduce parser allocations in allocateCommentsP

In the most common case, the comment queue is empty, so we can skip the
work of processing it. This reduces allocations by about 10% in the
parsing001 test.

Metric Decrease:
    MultiLayerModulesRecomp
    parsing001

- - - - -


30 changed files:

- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Match.hs
- compiler/GHC/HsToCore/Pmc.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/Rename/Utils.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Gen/App.hs
- compiler/GHC/Tc/Gen/Arrow.hs
- + compiler/GHC/Tc/Gen/Do.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Head.hs
- compiler/GHC/Tc/Gen/Match.hs
- compiler/GHC/Tc/Gen/Pat.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/TyCl/Instance.hs
- compiler/GHC/Tc/TyCl/PatSyn.hs
- compiler/GHC/Tc/TyCl/Utils.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3329df9f058027a78f650683e463e5a890a5a017...8811b8040d71fec1be90f4c84517e1e8f2f1613c

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3329df9f058027a78f650683e463e5a890a5a017...8811b8040d71fec1be90f4c84517e1e8f2f1613c
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/20240204/4bb08cd1/attachment.html>


More information about the ghc-commits mailing list