[Git][ghc/ghc][wip/9.6.4-backports] 13 commits: Fix unusable units and module reexport interaction (#21097)

Zubin (@wz1000) gitlab at gitlab.haskell.org
Thu Dec 14 09:44:26 UTC 2023 


Zubin pushed to branch wip/9.6.4-backports at Glasgow Haskell Compiler / GHC


Commits:
4b3c06cd by Sylvain Henry at 2023-12-14T14:00:30+05:30
Fix unusable units and module reexport interaction (#21097)

This commit fixes an issue with ModUnusable introduced in df0f148feae.

In mkUnusableModuleNameProvidersMap we traverse the list of unusable
units and generate ModUnusable origin for all the modules they contain:
exposed modules, hidden modules, and also re-exported modules. To do
this we have a two-level map:

  ModuleName -> Unit:ModuleName (aka Module) -> ModuleOrigin

So for each module name "M" in broken unit "u" we have:
  "M" -> u:M -> ModUnusable reason

However in the case of module reexports we were using the *target*
module as a key. E.g. if "u:M" is a reexport for "X" from unit "o":
   "M" -> o:X -> ModUnusable reason

Case 1: suppose a reexport without module renaming (u:M -> o:M) from
unusable unit u:
   "M" -> o:M -> ModUnusable reason

Here it's claiming that the import of M is unusable because a reexport
from u is unusable. But if unit o isn't unusable we could also have in
the map:
   "M" -> o:M -> ModOrigin ...

Issue: the Semigroup instance of ModuleOrigin doesn't handle the case
(ModUnusable <> ModOrigin)

Case 2: similarly we could have 2 unusable units reexporting the same module
without renaming, say (u:M -> o:M) and (v:M -> o:M) with u and v
unusable. It gives:

  "M" -> o:M -> ModUnusable ... (for u)
  "M" -> o:M -> ModUnusable ... (for v)

Issue: the Semigroup instance of ModuleOrigin doesn't handle the case
(ModUnusable <> ModUnusable).

This led to #21097, #16996, #11050.

To fix this, in this commit we make ModUnusable track whether the module
used as key is a reexport or not (for better error messages) and we use
the re-export module as key. E.g. if "u:M" is a reexport for "o:X" and u
is unusable, we now record:

    "M" -> u:M -> ModUnusable reason reexported=True

So now, we have two cases for a reexport u:M -> o:X:
   - u unusable: "M" -> u:M -> ModUnusable ... reexported=True
   - u usable:   "M" -> o:X -> ModOrigin   ... reexportedFrom=u:M

The second case is indexed with o:X because in this case the Semigroup
instance of ModOrigin is used to combine valid expositions of a module
(directly or via reexports).

Note that module lookup functions select usable modules first (those who
have a ModOrigin value), so it doesn't matter if we add new ModUnusable
entries in the map like this:

  "M" -> {
    u:M -> ModUnusable ... reexported=True
    o:M -> ModOrigin ...
  }

The ModOrigin one will be used. Only if there is no ModOrigin or
ModHidden entry will the ModUnusable error be printed. See T21097 for an
example printing several reasons why an import is unusable.

(cherry picked from commit cee81370cd6ef256f66035e3116878d4cb82e28b)

- - - - -
52b3886a by Zubin Duggal at 2023-12-14T14:03:48+05:30
driver: Ensure we actually clear the interactive context before reloading

Previously we called discardIC, but immediately after set the session
back to an old HscEnv that still contained the IC

Partially addresses #24107
Fixes #23405

(cherry picked from commit fa148f6ed43f915f2ae40302dda1b8bae39512af)

- - - - -
9e2a2c47 by Zubin Duggal at 2023-12-14T14:03:56+05:30
driver: Ensure we force the lookup of old build artifacts before returning the build plan

This prevents us from retaining all previous build artifacts in memory until a
recompile finishes, instead only retaining the exact artifacts we need.

Fixes #24118

(cherry picked from commit a62d4cb25b805dd7e12476db97a667fd542ea006)

- - - - -
1d381ec6 by Zubin Duggal at 2023-12-14T14:04:03+05:30
testsuite: add test for #24118 and #24107

MultiLayerModulesDefsGhci was not able to catch the leak because it uses
:l which discards the previous environment.

Using :r catches both of these leaks
(cherry picked from commit 244d3315352376eb7b946843fb0c512412842d7d)

- - - - -
87bdf022 by Zubin Duggal at 2023-12-14T14:06:14+05:30
compiler: Add some strictness annotations to ImportSpec and related constructors
This prevents us from retaining entire HscEnvs.

Force these ImportSpecs when forcing the GlobalRdrEltX

Adds an NFData instance for Bag

Fixes #24107

(cherry picked from commit 306cb4e3e02e466f6c5a57c1a65fd2a5d13b3f89)

- - - - -
726603c6 by Zubin Duggal at 2023-12-14T14:19:29+05:30
compiler: Force IfGlobalRdrEnv in NFData instance.

(cherry picked from commit 77a3b580f561e62f5ac7ebf6588199575aafd3b4)

- - - - -
bc0c7d79 by Pierre Le Marre at 2023-12-14T14:22:50+05:30
Update to Unicode 15.1.0

See: https://www.unicode.org/versions/Unicode15.1.0/
(cherry picked from commit 778c84b61679a8bb9dd83e2c41156abc0f39abd3)

- - - - -
0d9c8f18 by Simon Peyton Jones at 2023-12-14T14:29:37+05:30
Add an extra check in kcCheckDeclHeader_sig

Fix #24083 by checking for a implicitly-scoped type variable that is not
actually bound.  See Note [Disconnected type variables] in GHC.Tc.Gen.HsType

For some reason, on aarch64-darwin we saw a 2.8% decrease in compiler
allocations for MultiLayerModulesTH_Make; but 0.0% on other architectures.

Metric Decrease:
    MultiLayerModulesTH_Make

(cherry picked from commit 6dbab1808bfbe484b3fb396aab1d105314f918d8)

- - - - -
a07dd65e by Simon Peyton Jones at 2023-12-14T14:49:23+05:30
Second fix to #24083

My earlier fix turns out to be too aggressive for data/type families

See wrinkle (DTV1) in Note [Disconnected type variables]

(cherry picked from commit 2776920e642544477a38d0ed9205d4f0b48a782e)

- - - - -
0f0111d5 by Zubin Duggal at 2023-12-14T15:11:19+05:30
Bump array submodule to 0.5.6.0

- - - - -
5be50e5a by Matthew Pickering at 2023-12-14T15:13:53+05:30
libraries: Bump filepath to 1.4.200.1 and unix to 2.8.4.0

Updates filepath submodule
Updates unix submodule

Fixes #24240

(cherry picked from commit 36b9a38cc45a26865c4e45f4949e519a5dede76d)

- - - - -
a7841019 by Matthew Pickering at 2023-12-14T15:14:03+05:30
Submodule linter: Allow references to tags

We modify the submodule linter so that if the bumped commit is a
specific tag then the commit is accepted.

Fixes #24241

(cherry picked from commit 91ff0971df64b04938d011fe1562320c5d90849a)

- - - - -
540c96eb by Zubin Duggal at 2023-12-14T15:14:15+05:30
hadrian: set -Wno-deprecations for directory and Win32

The filepath bump to 1.4.200.1 introduces a deprecation warning.

See https://gitlab.haskell.org/ghc/ghc/-/issues/24240
    https://github.com/haskell/filepath/pull/206

(cherry picked from commit 86f652dc9a649e59e643609c287a510a565f5408)

- - - - -


30 changed files:

- compiler/GHC/Data/Bag.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Iface/Errors.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/Hint.hs
- compiler/GHC/Types/Hint/Ppr.hs
- compiler/GHC/Types/Name/Occurrence.hs
- compiler/GHC/Types/Name/Reader.hs
- compiler/GHC/Unit/Finder.hs
- compiler/GHC/Unit/Finder/Types.hs
- compiler/GHC/Unit/Module/ModIface.hs
- compiler/GHC/Unit/State.hs
- hadrian/src/Settings/Warnings.hs
- libraries/array
- libraries/base/GHC/Unicode/Internal/Char/DerivedCoreProperties.hs
- libraries/base/GHC/Unicode/Internal/Char/UnicodeData/GeneralCategory.hs
- libraries/base/GHC/Unicode/Internal/Char/UnicodeData/SimpleLowerCaseMapping.hs
- libraries/base/GHC/Unicode/Internal/Char/UnicodeData/SimpleTitleCaseMapping.hs
- libraries/base/GHC/Unicode/Internal/Char/UnicodeData/SimpleUpperCaseMapping.hs
- libraries/base/GHC/Unicode/Internal/Version.hs
- libraries/base/changelog.md
- libraries/base/tests/unicode003.stdout
- libraries/base/tools/ucd2haskell/ucd.sh
- libraries/base/tools/ucd2haskell/unicode_version
- libraries/filepath
- libraries/unix
- linters/lint-submodule-refs/Main.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/aee7728acd04eecf12f1e3411dfb50e4e86b33eb...540c96eb7af7cbca4673a51b9a19498247a2e6ed

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/aee7728acd04eecf12f1e3411dfb50e4e86b33eb...540c96eb7af7cbca4673a51b9a19498247a2e6ed
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/20231214/a8bc98c8/attachment-0001.html>

More information about the ghc-commits mailing list