[Git][ghc/ghc][master] 6 commits: Revert !4655: Stop 'import "base" Prelude' removing implicit Prelude import

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Thu Sep 26 16:09:54 UTC 2024



Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC


Commits:
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

- - - - -


26 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Parser/Header.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Unit/State.hs
- compiler/GHC/Unit/Types.hs
- docs/users_guide/exts/rebindable_syntax.rst
- libraries/base/base.cabal.in
- libraries/base/src/Control/Monad/Zip.hs
- libraries/base/src/Data/List/NonEmpty.hs
- libraries/ghc-internal/ghc-internal.cabal.in
- libraries/ghc-internal/src/GHC/Internal/Base.hs
- + libraries/ghc-internal/src/GHC/Internal/Control/Monad/Zip.hs
- libraries/ghc-internal/src/GHC/Internal/Data/List/NonEmpty.hs
- rts/include/RtsAPI.h
- testsuite/tests/backpack/should_compile/bkp16.stderr
- testsuite/tests/backpack/should_fail/bkpfail17.stderr
- testsuite/tests/backpack/should_fail/bkpfail19.stderr
- testsuite/tests/iface/IfaceSharingIfaceType.hs
- testsuite/tests/iface/IfaceSharingName.hs
- testsuite/tests/interface-stability/base-exports.stdout
- testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs
- testsuite/tests/interface-stability/base-exports.stdout-mingw32


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/bb030d0d4374f6a30432e821fda7d0ef699425f5...d3dacdfb9f739541ca6ed2659d35723677557955

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/bb030d0d4374f6a30432e821fda7d0ef699425f5...d3dacdfb9f739541ca6ed2659d35723677557955
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/4698c112/attachment.html>


More information about the ghc-commits mailing list