[Git][ghc/ghc][wip/T25281] 15 commits: Don't compile `asBox` with -fprof-late

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Thu Sep 26 23:37:24 UTC 2024 


Simon Peyton Jones pushed to branch wip/T25281 at Glasgow Haskell Compiler / GHC


Commits:
783c8b29 by Matthew Pickering at 2024-09-26T12:07:44-04:00
Don't compile `asBox` with -fprof-late

The `asBox` function is intended to store exactly the closure which the
user passes to it. Placing a cost centre on asBox introduces a thunk,
which violates this expectation and can change the result of using asBox
when profiling is enabled.

See #25212 for more details and ample opportunity to discuss if this is
a bug or not.

- - - - -
0967dcc7 by Matthew Pickering at 2024-09-26T12:07:44-04:00
Fix normalisation of .prof files

Fix 1: If a cost centre contained CAF then the normalisation was
corrupted, now only check if CAF is at the start of a line.

Fix 2: "no location info" contain a space, which messed up the next
normalisation logic which assumed that columns didn't have spaced in.

- - - - -
9eda1cb9 by Matthew Pickering at 2024-09-26T12:07:44-04:00
testsuite: Fix normalisation of prof_files removing newlines

These normalisation steps were collapsing lines together, which made
subsequent normalisation steps fail.

```
foo x y z
CAF x y z
qux x y z
```

was getting normalised to

```
foo x y z qux x y z
```

which means that subsequent line based filters would not work correctly.

- - - - -
2b25f9e2 by Matthew Pickering at 2024-09-26T12:07:44-04:00
packaging: Enable late-ccs for release flavour

This enables late cost centres when building profiled libraries and
subsequently greatly improves the resolution of cost centre stacks when
profiling.

This patch also introduces the `grep_prof` test modifier which is used
to apply a further filter to the .prof file before they are compared.

Fixes #21732

-------------------------
Metric Increase:
    libdir
-------------------------

- - - - -
bb030d0d by Brandon Chinn at 2024-09-26T12:08:21-04:00
Replace manual string lexing (#25158)

Metric Increase:
    MultilineStringsPerf

This commit replaces the manual string lexing logic with native Alex
lexing syntax. This aligns the lexer much closer to the Haskell Report,
making it easier to see how the implementation and spec relate. This
slightly increases memory usage when compiling multiline strings because
we now have two distinct phases: lexing the multiline string with Alex
and post-processing the string afterwards. Before, these were done at
the same time, but separating them allows us to push as much logic into
normal Alex lexing as possible.

Since multiline strings are a new feature, this regression shouldn't be
too noticeable. We can optimize this over time.

- - - - -
16742987 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Revert !4655: Stop 'import "base" Prelude' removing implicit Prelude import

This behaviour is problematic for the principle reason that `import
Prelude` may not refer to the `base` package, and in which case
importing an entirely unrelated module causing your implicit prelude to
leave the scope is extremely surprising. See the added test for this
example. Discussion on #17045.

The secondary reason for reverting this patch is that "base" can't be a
wired in package any more (see #24903), so we have to remove special
logic which singles out base from the compiler.

The rule for implicit shadowing is now simply:

* If you write import Prelude (..) then you don't get an implicit prelude import
* If you write import "foobar" Prelude (..) for all pkgs foobar,
  you get an implicit import of prelude.

If you want to write a package import of Prelude, then you can enable
`NoImplicitPrelude` for the module in question to recover the behaviour
of ghc-9.2-9.10.

Fixes #17045

- - - - -
57c50f41 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Rename COMPILING_BASE_PACKAGE to COMPILING_GHC_INTERNAL_PACKAGE

The COMPILING_BASE_PACKAGE macro is concerned with issues defining
symbols and using symbols in the same compilation unit. However, these
symbols now exist in ghc-internal rather than base, so we should rename
the macro accordingly.

The code is guards is likely never used as we never produce windows DLLs
but it is simpler to just perform the renaming for now.

These days there is little doubt that this macro defined in this ad-hoc
manner would be permitted to exist, but these days are not those days.

Fixes #25221

- - - - -
70764243 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Preload ghc-internal rather than base

This occurence of baseUnitId was missed when moving the bulk of internal
definitions into `ghc-internal`.

We need to remove this preloading of `base` now because `base` should
not be wired in.

Towards #24903

- - - - -
12915609 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Remove Data.List compat warning

There is currently a warning implemented in -Wcompat which warns you
when importing Data.List in a non-qualified manner.

```
A.hs:3:8: warning: [-Wcompat-unqualified-imports]
    To ensure compatibility with future core libraries changes
    imports to Data.List should be
    either qualified or have an explicit import list.
  |
3 | import Data.List
  |        ^^^^^^^^^
Ok, one module loaded.
```

GHC ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/17244
CLC discussion: https://groups.google.com/g/haskell-core-libraries/c/q3zHLmzBa5E

This warning was implemented as part of the migration to making
Data.List monomorphic again (and to be used like Data.Set, Data.Map
etc). That doesn't seem like it happened, and I imagine that the current
CLC would require a new proposal anyway in order to do that now. It's
not clear in any case what "future core libraries changes" we are
waiting to happen before this warning can be removed.

Given the first phase of the proposal has lasted 5 years it doesn't seem
that anyone is motivated to carry the proposal to completion. It does
seem a bit unnecessary to include a warning in the compiler about
"future changes to the module" when there's no timeline or volunteer to
implement these changes.

The removal of this warning was discussed again at:
https://github.com/haskell/core-libraries-committee/issues/269

During the discussion there was no new enthusiasm to move onto the next
stages of the proposal so we are removing the warning to unblock the
reinstallable "base" project (#24903)

Fixes #24904

- - - - -
d4e4d498 by Matthew Pickering at 2024-09-26T12:08:57-04:00
Move Control.Monad.Zip into ghc-internal

mzip is wired in and therefore needs to be in ghc-internal.

Fixes #25222

Towards #24903

- - - - -
d3dacdfb by Matthew Pickering at 2024-09-26T12:08:57-04:00
Unwire the base package

This patch just removes all the functions related to wiring-in the base
package and the `-this-unit-id=base` flag from the cabal file.

After this commit "base" becomes just like any other package and the
door is opened to moving base into an external repo and releasing base
on a separate schedule to the rest of ghc.

Closes #24903

- - - - -
8819aef9 by Sebastian Graf at 2024-09-26T23:08:47+01:00
Pmc: Improve implementation of -Wincomplete-record-selectors (#24824, #24891)

We now incorporate the result type of unsaturated record selector applications
as well as consider long-distance information in getField applications.

See the updated Note [Detecting incomplete record selectors].

Fixes #24824 and #24891.

- - - - -
10865673 by Sebastian Graf at 2024-09-26T23:08:47+01:00
Pmc: Improve warning messages of -Wincomplete-record-selectors

... as suggested by Adam Gundry in !12685.

- - - - -
58cb0ecd by Simon Peyton Jones at 2024-09-26T23:08:47+01:00
Just a start on #25281

- - - - -
c7463270 by Simon Peyton Jones at 2024-09-27T00:37:03+01:00
Wibbles

- - - - -


30 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Core/ConLike.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Errors/Ppr.hs
- compiler/GHC/HsToCore/Errors/Types.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Monad.hs
- compiler/GHC/HsToCore/Pmc.hs
- compiler/GHC/HsToCore/Types.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/CharClass.hs
- compiler/GHC/Parser/Errors/Ppr.hs
- compiler/GHC/Parser/Errors/Types.hs
- compiler/GHC/Parser/Header.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/String.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Gen/App.hs
- compiler/GHC/Tc/Instance/Class.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/TyCl/Utils.hs
- compiler/GHC/Tc/Types/CtLoc.hs
- compiler/GHC/Tc/Types/LclEnv.hs
- compiler/GHC/Tc/Utils/Monad.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/Id/Info.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/740c3d27332b9673175d4dfe4e1040d65ac5ba2a...c7463270bdb2fc0ce6cedf235d05c6573599a3cc

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/740c3d27332b9673175d4dfe4e1040d65ac5ba2a...c7463270bdb2fc0ce6cedf235d05c6573599a3cc
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/20240926/b30c7879/attachment-0001.html>

More information about the ghc-commits mailing list