[Git][ghc/ghc][wip/sand-witch/infix-type-data] 5 commits: Bump bytestring submodule to something closer to 0.12.1

Andrei Borzenkov (@sand-witch) gitlab at gitlab.haskell.org
Mon Feb 5 10:12:19 UTC 2024



Andrei Borzenkov pushed to branch wip/sand-witch/infix-type-data 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.

- - - - -
0df8ce27 by Vladislav Zavialov at 2024-02-04T03:55:14-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

- - - - -
5e206e03 by Andrei Borzenkov at 2024-02-05T14:12:09+04:00
Namespace specifiers for fixity signatures

Updates haddock submodule.

- - - - -


29 changed files:

- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- 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.y
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Bind.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


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5148524896905d21bfaf39f13349dd83af4f99fa...5e206e0394f47b3bc0ff211a24afc19c6986e4c8

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5148524896905d21bfaf39f13349dd83af4f99fa...5e206e0394f47b3bc0ff211a24afc19c6986e4c8
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/20240205/2a3b3ed0/attachment-0001.html>


More information about the ghc-commits mailing list