[Git][ghc/ghc][wip/slide_x_0] 8 commits: Rework built-in and punned names (#25174, #25179, #25180, #25182)

Tue Jan 28 15:04:58 UTC 2025

Matthew Pickering pushed to branch wip/slide_x_0 at Glasgow Haskell Compiler / GHC

Commits:
51e3ec83 by Vladislav Zavialov at 2025-01-22T20:41:32+03:00
Rework built-in and punned names (#25174, #25179, #25180, #25182)

This patch rewrites part of the logic for dealing with built-in and
punned names, making it more principled and fixing a few bugs.

* Kill off filterCTuple. Its purpose was to improve pretty-printing of
  constraint tuples, and the appropriate place for this is namePun_maybe.

* Remove unitTyCon, unboxedUnitTyCon, and soloTyCon from wiredInTyCons.
  Their inclusion in the list was a workaround for shoddy logic in
  lookupOrigNameCache. Now we treat tuples of all arities uniformly.

* In isBuiltInOcc_maybe, only match on actual built-in syntax, e.g. "FUN"
  shouldn't be there (#25174). Also take ListTuplePuns into account (#25179).

* When matching OccNames, use the ShortByteString directly to avoid
  potentially costly conversions to ByteString and String.

* Introduce isInfiniteFamilyOrigName_maybe, a purpose-built helper for
  looking up tuples/sums in the OrigNameCache. This clears up the previously
  convoluted relation between the orig name cache and built-in syntax.

* Reuse isKnownOrigName_maybe to eliminate the need for isPunOcc_maybe.

* Classify MkSolo and MkSolo# as UserSyntax, thus fixing whole-module
  reexports (#25182).

* Teach valid-hole-fits about tuples, unboxed tuples, and unboxed sums,
  up to a certain arity (#25180).

* Drop the unnecessary special case for unary constraint tuples in the
  type checker (finish_tuple). It was a workaround for the lack of CSolo.

* Update Notes and other comments, add tests.

- - - - -
85c60aea by Teo Camarasu at 2025-01-23T18:06:21-05:00
doc: Add documentation for -XDoAndIfThenElse

Resolves #18631

Co-authored-by: Richard Eisenberg <rae at cs.brynmawr.edu>

- - - - -
4495e48f by Brandon Chinn at 2025-01-24T11:54:24-05:00
Break out GHC.Parser.Lexer.Interface

- - - - -
4f8fc11e by Brandon Chinn at 2025-01-24T11:54:24-05:00
Fix lexing comments in multiline strings (#25609)

Metric Decrease:
    MultiLayerModulesRecomp
    parsing001

- - - - -
e7ab778f by Matthew Pickering at 2025-01-24T11:55:01-05:00
testsuite: Pass TEST_HC_OPTS to many more tests

This passes `-dno-debug-output` to the test and `-dlint.

- - - - -
c3593101 by Sylvain Henry at 2025-01-24T23:12:20-05:00
Merge ghc-prim's modules into ghc-internal (#24453)

ghc-internal becomes the only wired-in package exposing primitives.

There are some minor GHC allocation regressions, but they barely cross
the thresholds and only with the wasm backend. They're likely due to
longer symbols (ghc-internal vs ghc-prim, GHC.Internal.X vs GHC.X).

Metric Increase:
    T13035
    T1969
    T4801
    T9961

- - - - -
70f7741a by Jens Petersen at 2025-01-24T23:12:58-05:00
hp2ps/Utilities.c: add extern parameter types for malloc and realloc for C23

use portable C types!

- - - - -
d811e356 by Matthew Pickering at 2025-01-28T15:04:48+00:00
bytecode: Do not generate `SLIDE x 0` instructions

SLIDE x 0 is a no-op as it means to shift x elements of the stack by no
spaces. In the interpreter, this results in a loop which copies an array
element into the same place.

I have instrumented GHCi to count how many of these instructions are interpreted.
The workload was `ghc` compiling two simple modules.

Total no-op slides: 7793476
Total slides: 11413289
Percentage useless (slides): 68%
Percentage uselss of total instructions: 9%

- - - - -

30 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/Uniques.hs
- compiler/GHC/ByteCode/Linker.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/Config/Core/Rules.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/HsToCore/Foreign/JavaScript.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/Parser/Errors/Ppr.hs
- compiler/GHC/Parser/HaddockLex.x
- compiler/GHC/Parser/Header.hs
- compiler/GHC/Parser/Lexer.x
- + compiler/GHC/Parser/Lexer/Interface.hs
- + compiler/GHC/Parser/Lexer/String.x
- compiler/GHC/Plugins.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Runtime/Interpreter/JS.hs
- compiler/GHC/StgToByteCode.hs
- compiler/GHC/StgToJS/Linker/Linker.hs
- compiler/GHC/StgToJS/Linker/Utils.hs
- compiler/GHC/Tc/Errors/Hole.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Gen/Default.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Gen/Splice.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d736522d5795cdabfa83b56d92f7b6588293587d...d811e35670a1e5df0e7a629da8889dc0eaf0c7ab

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d736522d5795cdabfa83b56d92f7b6588293587d...d811e35670a1e5df0e7a629da8889dc0eaf0c7ab
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/20250128/8af915a7/attachment.html>