Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: 042b3a8a by Duncan Coutts at 2026-04-28T19:47:36-04:00 Make cmm 'import "package" name;' syntax use consistent label types There is a little-used syntactic form in cmm imports: import "package" foo; Which means to import foo from the given package (unit id, specified as a string). This syntax is somewhat reminiscent of GHC's package import extension. This syntax form is not used in the rts cmm code, nor any of the boot libraries. It may not be used at all. Unclear. Change the kind of CLabel this syntax generates to be consistent with the others. The other cmm imports use ForeignLabel with ForeignLabelInExternalPackage. For some reason this form was using CmmLabel. Change that to also be ForeignLabel but with ForeignLabelInPackage. This specifies a specific package, rather than an unnamed external package. - - - - - 7e026668 by Duncan Coutts at 2026-04-28T19:47:36-04:00 Change default cmm import statements to be internal Previously a cmm statement like: import foo; meant to expect the symbol from a different shared library than the current one. Now it means to expect the symbol from the same shared library as the current one. We'll add explicit syntax to indicate that it's a foreign import. Most existing uses are in fact intenal (rts to rts), so few imports will need to be annotated foreign. Examples would include cmm code in libraries (other than the rts) that need to access RTS APIs. In practice, this makes no difference whatsoever at the moment on any platform other than windows (where building Haskell libs as shared libs does not fully work yet), since the 'labelDynamic' treats all such labels as foreign, irrespective of the foreign label source. - - - - - 1c083614 by Duncan Coutts at 2026-04-28T19:47:36-04:00 Add cmm import syntax 'import DATA foo;' as better name for CLOSURE The existing syntax is: import CLOSURE foo; The new syntax is import DATA foo; This means to interpret the symbol foo as refering to data (i.e. a global constant or variable) rather than to code (a function). The historical syntax for this uses CLOSURE, which is rather misleading. Presumably this was done to avoid introducing new reserved words. Be less squemish about new reserved words and add DATA and use that. Keep the existing CLOSURE syntax as an alias for compatibility. - - - - - 7ef0d0c9 by Duncan Coutts at 2026-04-28T19:47:36-04:00 Add cmm 'import extern name;' syntax Since the default for cmm imports is now for symbols within the same shared object, we need a way to indicate we want a symbol from an external shared object: import extern foo; -- for a function import extern DATA foo; -- for data This adds a new reserved word 'extern'. We don't expect to have to use this much. Most cmm imports are intra-DSO. This makes no difference currently on ELF and MachO platforms, but does make a difference to the linking conventions on PE (Windows). In future it's plausible we could take make distinctions on ELF or MachO, so it's worth trying to get it right. Windows can be the guinea pig. - - - - - f0dd79b7 by Duncan Coutts at 2026-04-28T19:47:36-04:00 Add cmm syntax 'import "package" DATA foo;' for completeness We already have: import DATA foo; -- for data imports import "package" foo; -- for imports from a given unitid There's no reason not to have both at once: import "package" DATA foo; So add that. - - - - - 29a658bb by Duncan Coutts at 2026-04-28T19:47:36-04:00 Improve the commentary for the cmm import grammar. AFAIK, this is the only place where GHC-style Cmm syntax is documented. - - - - - be97e9ab by Duncan Coutts at 2026-04-28T19:47:36-04:00 Add a changelog.d entry for the .cmm import syntax changes - - - - - 1db4ee55 by Wolfgang Jeltsch at 2026-04-28T19:47:38-04:00 Move code that uses `GHC.Internal.Text.Read` into `base` This contribution serves to remove all dependencies on `GHC.Internal.Text.Read` from within `ghc-internal`, so that the implementation of `Text.Read` and ultimately more reading-related code can be moved to `base` as well. The following things are moved from `ghc-internal` to `base`: * I/O-related `Read` instances * Most of the `Numeric` implementation * The instance `Read ByteOrder` * The `parseVersion` operation * The `readConstr` operation Metric Increase: LinkableUsage01 T9198 T12425 T13035 T13820 - - - - - 13db5e7c by David Eichmann at 2026-04-28T19:47:38-04:00 Hadrian: withResponseFile outputs response file when verbodity is Verbose At the Verbose verbosity, shake will display full commandlines. With the use of response files, the full command is hidden. That makes it hard to run the command manually. This commit outputs the contents of the response file so that that full command can be recreated and also hints at the use of the --keep-response-files hadrian flag. - - - - - f7e0299b by Duncan Coutts at 2026-04-28T19:47:38-04:00 Use response files for hadrian linking with ghc (support long command lines) In future support for windows dynamic linking, we expect long command lines for linking dll files with ghc. Experiments with dynamic linking the ghc-internal library yielded a link command well over 32kb. We did not encounter this before for static libs, since we already use ar's @file feature (if available, which it is for the llvm toolchain). Co-authored-by: David Eichmann <davide@well-typed.com> - - - - - ba1c57b6 by Cheng Shao at 2026-04-28T19:47:40-04:00 compiler: avoid unique OccNames for internal Names in bytecode objects This patch improves bytecode object serialization logic by avoiding the construction of unique `OccName`s when serializing/deserializing internal `Name`s. Closes #27213. ------------------------- Metric Decrease: LinkableUsage01 ------------------------- - - - - - 83413382 by Vladislav Zavialov at 2026-04-28T19:47:41-04:00 Replace GHC 9.16 references with GHC 10.0 - - - - - 39 changed files: - + changelog.d/cmm-import-syntax-changes - compiler/GHC/ByteCode/Binary.hs - compiler/GHC/Cmm/Lexer.x - compiler/GHC/Cmm/Parser.y - compiler/GHC/Driver/Flags.hs - docs/users_guide/debug-info.rst - docs/users_guide/exts/explicit_namespaces.rst - docs/users_guide/exts/linear_types.rst - docs/users_guide/exts/modifiers.rst - docs/users_guide/exts/qualified_strings.rst - docs/users_guide/exts/required_type_arguments.rst - docs/users_guide/using-warnings.rst - docs/users_guide/using.rst - hadrian/src/Builder.hs - hadrian/src/Hadrian/Builder.hs - hadrian/src/Hadrian/Utilities.hs - hadrian/src/Settings/Builders/Ghc.hs - libraries/base/src/Data/Data.hs - libraries/base/src/Data/Version.hs - libraries/base/src/GHC/ByteOrder.hs - libraries/base/src/Numeric.hs - libraries/base/src/System/IO.hs - libraries/base/src/Text/Printf.hs - libraries/ghc-internal/src/GHC/Internal/Data/Data.hs - libraries/ghc-internal/src/GHC/Internal/Data/Version.hs - libraries/ghc-internal/src/GHC/Internal/IO/Device.hs - libraries/ghc-internal/src/GHC/Internal/IO/Handle/Types.hs - libraries/ghc-internal/src/GHC/Internal/IO/IOMode.hs - libraries/ghc-internal/src/GHC/Internal/Numeric.hs - libraries/ghc-internal/src/GHC/Internal/Read.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 - testsuite/tests/interface-stability/base-exports.stdout-ws-32 - testsuite/tests/plugins/plugins09.stdout - testsuite/tests/plugins/plugins10.stdout - testsuite/tests/plugins/plugins11.stdout - testsuite/tests/plugins/static-plugins.stdout - testsuite/tests/typecheck/should_fail/all.T The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2952c860441125e2ec110d91b123acc... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2952c860441125e2ec110d91b123acc... You're receiving this email because of your account on gitlab.haskell.org.