[Git][ghc/ghc][wip/backports-9.8-2] 7 commits: Fix haddock source links and hyperlinked source

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Fri Oct 11 15:19:41 UTC 2024



Ben Gamari pushed to branch wip/backports-9.8-2 at Glasgow Haskell Compiler / GHC


Commits:
3dc62f2e by Matthew Pickering at 2024-10-11T11:16:35-04:00
Fix haddock source links and hyperlinked source

There were a few issues with the hackage links:

1. We were using the package id rather than the package name for the
   package links. This is fixed by now allowing the template to mention
   %pkg% or %pkgid% and substituing both appropiatly.
2. The `--haddock-base-url` flag is renamed to `--haddock-for-hackage`
   as the new base link works on a local or remote hackage server.
3. The "src" path including too much stuff, so cross-package source
   links were broken as the template was getting double expanded.

Fixes #24086

(cherry picked from commit 23f2a478b7dc6b61cab86cf7d0db7fec8a6d9a1f)

- - - - -
3a033e29 by Rodrigo Mesquita at 2024-10-11T11:16:35-04:00
rts: free error message before returning

Fixes a memory leak in rts/linker/PEi386.c

(cherry picked from commit dd530bb7e22e953e4cec64a5fd6c39fddc152c6f)

- - - - -
20f80b77 by Cheng Shao at 2024-10-11T11:16:35-04:00
rts: add missing ccs_mutex guard to internal_dlopen

See added comment for details. Closes #24423.

- - - - -
2166d290 by Ben Gamari at 2024-10-11T11:16:35-04:00
rts/linker: Don't unload native objects when dlinfo isn't available

To do so is unsafe as we have no way of identifying references to
symbols provided by the object.

Fixes #24513. Fixes #23993.

- - - - -
fc1dcd02 by Alexis King at 2024-10-11T11:16:35-04:00
linker: Avoid linear search when looking up Haskell symbols via dlsym

See the primary Note [Looking up symbols in the relevant objects] for a
more in-depth explanation.

When dynamically loading a Haskell symbol (typical when running a splice or
GHCi expression), before this commit we would search for the symbol in
all dynamic libraries that were loaded. However, this could be very
inefficient when too many packages are loaded (which can happen if there are
many package dependencies) because the time to lookup the would be
linear in the number of packages loaded.

This commit drastically improves symbol loading performance by
introducing a mapping from units to the handles of corresponding loaded
dlls. These handles are returned by dlopen when we load a dll, and can
then be used to look up in a specific dynamic library.

Looking up a given Name is now much more precise because we can get
lookup its unit in the mapping and lookup the symbol solely in the
handles of the dynamic libraries loaded for that unit.

In one measurement, the wait time before the expression was executed
went from +-38 seconds down to +-2s.

This commit also includes Note [Symbols may not be found in pkgs_loaded],
explaining the fallback to the old behaviour in case no dll can be found
in the unit mapping for a given Name.

Fixes #23415

Co-authored-by: Rodrigo Mesquita (@alt-romes)
(cherry picked from commit e008a19a7f9e8f22aada0b4e1049744f49d39aad)

- - - - -
9d1ecdb9 by Ben Gamari at 2024-10-11T11:16:35-04:00
hadrian: Update bootstrap plans

- - - - -
1413e1dd by Rodrigo Mesquita at 2024-10-11T11:16:35-04:00
rts: Make addDLL a wrapper around loadNativeObj

Rewrite the implementation of `addDLL` as a wrapper around the more
principled `loadNativeObj` rts linker function. The latter should be
preferred while the former is preserved for backwards compatibility.

`loadNativeObj` was previously only available on ELF platforms, so this
commit further refactors the rts linker to transform loadNativeObj_ELF
into loadNativeObj_POSIX, which is available in ELF and MachO platforms.

The refactor made it possible to remove the `dl_mutex` mutex in favour
of always using `linker_mutex` (rather than a combination of both).

Lastly, we implement `loadNativeObj` for Windows too.

(cherry picked from commit dcfaa190e1e1182a2efe4e2f601affbb832a49bb)

- - - - -


30 changed files:

- .gitlab/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/GHC/ByteCode/Linker.hs
- compiler/GHC/Driver/Plugins.hs
- compiler/GHC/Linker/Loader.hs
- compiler/GHC/Linker/MacOS.hs
- compiler/GHC/Linker/Types.hs
- compiler/GHC/Runtime/Interpreter.hs
- hadrian/README.md
- hadrian/bootstrap/generate_bootstrap_plans
- hadrian/src/CommandLine.hs
- hadrian/src/Settings/Builders/Haddock.hs
- libraries/ghci/GHCi/Message.hs
- libraries/ghci/GHCi/ObjLink.hs
- libraries/ghci/GHCi/Run.hs
- rts/CheckUnload.c
- rts/Linker.c
- rts/LinkerInternals.h
- rts/Profiling.c
- rts/Profiling.h
- rts/RtsSymbols.c
- rts/include/rts/Linker.h
- rts/linker/Elf.c
- rts/linker/Elf.h
- + rts/linker/LoadNativeObjPosix.c
- + rts/linker/LoadNativeObjPosix.h
- rts/linker/PEi386.c
- rts/linker/PEi386.h
- rts/rts.cabal.in
- testsuite/tests/ghci/linking/dyn/T3372.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/34601024f6164efbf7dfd8ede7e5d820e55007fa...1413e1dd7a2d9161be986a66609b86e2de792b28

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/34601024f6164efbf7dfd8ede7e5d820e55007fa...1413e1dd7a2d9161be986a66609b86e2de792b28
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/20241011/e5978ede/attachment.html>


More information about the ghc-commits mailing list