[Git][ghc/ghc][wip/T26548] 15 commits: Remove `GHC.Desugar` from `base`

Simon Peyton Jones pushed to branch wip/T26548 at Glasgow Haskell Compiler / GHC Commits: 607b287b by Wolfgang Jeltsch at 2026-01-28T15:41:53+02:00 Remove `GHC.Desugar` from `base` `GHC.Desugar` was deprecated and should have been removed in GHC 9.14. However, the removal was forgotten, although there was a code block that was intended to trigger a compilation error when the GHC version in use was 9.14 or later. This code sadly didn’t work, because the `__GLASGOW_HASKELL__` macro was misspelled as `__GLASGOW_HASKELL`. - - - - - e8f5a45d by sterni at 2026-01-29T04:19:18-05:00 users_guide: fix runtime error during build with Sphinx 9.1.0 Appears that pathto is stricter about what it accepts now. Tested Sphinx 8.2.3 and 9.1.0 on the ghc-9.10 branch. Resolves #26810. Co-authored-by: Martin Weinelt - - - - - ce2d62fb by Jessica Clarke at 2026-01-29T19:48:51-05:00 PPC NCG: Use libcall for 64-bit cmpxchg on 32-bit PowerPC There is no native instruction for this, and even if there were a register pair version we could use, the implementation here is assuming the values fit in a single register, and we end up only using / defining the low halves of the registers. Fixes: b4d39adbb5 ("PrimOps: Add CAS op for all int sizes") Fixes: #23969 - - - - - 43d97761 by Michael Karcher at 2026-01-29T19:49:43-05:00 NCG for PPC: add pattern for CmmRegOff to iselExpr64 Closes #26828 - - - - - aeeb4a20 by Matthew Pickering at 2026-01-30T11:42:47-05:00 determinism: Use deterministic map for Strings in TyLitMap When generating typeable evidence the types we need evidence for all cached in a TypeMap, the order terms are retrieved from a type map determines the order the bindings appear in the program. A TypeMap is quite diligent to use deterministic maps, apart from in the TyLitMap, which uses a UniqFM for storing strings, whose ordering depends on the Unique of the FastString. This can cause non-deterministic .hi and .o files. An unexpected side-effect is the error message but RecordDotSyntaxFail8 changing. I looked into this with Sam and this change caused the constraints to be solved in a different order which results in a slightly different error message. I have accepted the new test, since the output before was non-deterministic and the new output is consistent with the other messages in that file. Fixes #26846 - - - - - 9e4d70c2 by Andrew Lelechenko at 2026-01-30T11:43:29-05:00 Upgrade text submodule to 2.1.4 - - - - - 631fa5ae by Recursion Ninja at 2026-01-31T22:30:11+00:00 Decouple `L.S.H.Decls` from importing `GHC.Types.Basic` Data-types within `GHC.Types.Basic` which describe components of the AST are migrated to `Language.Haskell.Syntax.Basic`. Related function definitions are also moved. Types moved to L.H.S. because they are part of the AST: * TopLevelFlag * RuleName Types moved from L.H.S. to GHC.Hs. because they are not needed in the AST: * TyConFlavour * TypeOrData * NewOrData Migrated instances: * `Outputable` instances moved to in `GHC.Utils.Outputable` * `Binary` instance of `Boxity` moved to to `GHC.Utils.Binary` * Other `Binary` instances are orphans to be migrated later. The `OverlapMode` data-type is given a TTG extension point. The `OverlapFlag` data-type, which depends on `OverlapMode`, is updated to support `OverlapMode` with a GHC "pass" type paramerter. In order to avoid module import cycles, `OverlapMode` and `OverlapFlag` are migrated to new modules (no way around this). * Migrated `OverlapMode` to new module `Language.Haskell.Syntax.Overlap` * Migrated `OverlapFlag` to new module `GHC.Hs.Decls.Overlap` - - - - - 9769cc03 by Simon Hengel at 2026-02-01T04:21:03-05:00 Update the documentation for MultiWayIf (fixes #25376) (so that it matches the implementation) - - - - - 5fc9442a by Peter Trommler at 2026-02-01T04:21:44-05:00 hadrian: Fix dependency generation for assembler Assembler files allow # for comments unless in column 1. A modern cpp for C treats those a preprocessor directives. We tell gcc that a .S file is assembler with cpp and not C. Fixes #26819 - - - - - 269c4087 by Simon Peyton Jones at 2026-02-01T19:38:10-05:00 Include current phase in the range for rule/unfoldings This MR fixes a bad loop in the compiler: #26826. The fix is to add (WAR2) to Note [What is active in the RHS of a RULE or unfolding?] in GHC.Core.Opt.Simplify.Utils - - - - - ddf1434f by Vladislav Zavialov at 2026-02-01T19:38:52-05:00 Refactor: merge HsMultilineString into HsString (#26860) Before this patch, HsLit defined two separate constructors to represent single-line and multi-line strings: data HsLit x ... | HsString (XHsString x) FastString | HsMultilineString (XHsMultilineString x) FastString I found this to be an unnecessary complication and an obstacle to unifying HsLit with HsTyLit. Now we use HsString for both kinds of literals. One user-facing change here is `ppr (HsString st s)` behaving differently for single-line strings containing newlines: x = "first line \ \asdf\n\ \second line" Previously, the literal was fed to `ftext` with its newlines, producing an ill-formed SDoc. This issue is now addressed by using `split` for both single-line and multi-line strings: vcat $ map text $ split '\n' (unpackFS src) See the parser/should_fail/T26860ppr test. In addition (and unrelatedly to the main payload of this patch), drop the unused pmPprHsLit helper. - - - - - 8bc23d68 by Simon Peyton Jones at 2026-02-02T09:35:06+00:00 Fix evaluated-ness bug in Simplifier This fixes #26548, an error which meant that we were failing to attach evaluated-ness flags to case-alternative-bound variables - - - - - 7d615601 by Simon Peyton Jones at 2026-02-02T09:35:06+00:00 Be a little less eager to inline ---> OtherCon [] = TrivArg OtherCon _ = NonTrivArg Make inlining a tiny bit more eager ---> OtherCon [] = NonTrivArg In particular x = mkSymMCo mco where mco is evaluated. We want that to inline, especially if the let is strict. Makes a significant difference in Rewrite.hs, Test case T9872b OtherCon [] arguments aren't interesting ---> OtherCon [] = TrivArg Remove white space Be a little less keen to inline This commit changes interestingArg to treat lambda as NonTrivArg rather than ValueArg. That makes parser combinators a bit less keen to inline. E.g. <|> p1 p2 = \x -> case p1 x of Yes -> ... No -> ... If we have a call (<|> arg1 arg2) where arg1 is a parser, and hence often visibly a lambda, it's no so great to inline <|>, because we are still stuck on x. This affects for example T17516 Just an experiment. - - - - - 97e75321 by Simon Peyton Jones at 2026-02-02T09:35:06+00:00 Wibbles In particular, a lambda is a value argument in interestingArg For some reason I had changed this and it made many things worse This wibble puts it back! - - - - - 70092bd0 by Simon Peyton Jones at 2026-02-02T09:35:06+00:00 Tracing in SpecConstr only - - - - - 81 changed files: - compiler/GHC/CmmToAsm/PPC/CodeGen.hs - compiler/GHC/Core/InstEnv.hs - compiler/GHC/Core/Map/Type.hs - compiler/GHC/Core/Opt/OccurAnal.hs - compiler/GHC/Core/Opt/Simplify/Env.hs - compiler/GHC/Core/Opt/Simplify/Inline.hs - compiler/GHC/Core/Opt/Simplify/Iteration.hs - compiler/GHC/Core/Opt/Simplify/Utils.hs - compiler/GHC/Core/Opt/SpecConstr.hs - compiler/GHC/Core/Opt/WorkWrap.hs - compiler/GHC/Hs/Decls.hs - + compiler/GHC/Hs/Decls/Overlap.hs - compiler/GHC/Hs/Instances.hs - compiler/GHC/Hs/Lit.hs - compiler/GHC/Hs/Syn/Type.hs - compiler/GHC/Hs/Utils.hs - compiler/GHC/HsToCore/Errors/Types.hs - compiler/GHC/HsToCore/Match/Literal.hs - compiler/GHC/HsToCore/Quote.hs - compiler/GHC/Iface/Ext/Ast.hs - compiler/GHC/Iface/Syntax.hs - compiler/GHC/Parser.y - compiler/GHC/Parser/String.hs - compiler/GHC/Rename/Env.hs - compiler/GHC/Rename/Expr.hs - compiler/GHC/Rename/Module.hs - compiler/GHC/Rename/Names.hs - compiler/GHC/Rename/Splice.hs - compiler/GHC/Tc/Deriv.hs - compiler/GHC/Tc/Deriv/Utils.hs - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Gen/Head.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/Utils/Env.hs - compiler/GHC/Tc/Utils/Instantiate.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/ThToHs.hs - compiler/GHC/Types/Basic.hs - compiler/GHC/Types/InlinePragma.hs - compiler/GHC/Types/Name.hs - compiler/GHC/Unit/Types.hs - compiler/GHC/Utils/Binary.hs - compiler/GHC/Utils/Outputable.hs - compiler/Language/Haskell/Syntax/Basic.hs - compiler/Language/Haskell/Syntax/Decls.hs - + compiler/Language/Haskell/Syntax/Decls/Overlap.hs - compiler/Language/Haskell/Syntax/Extension.hs - compiler/Language/Haskell/Syntax/Lit.hs - compiler/ghc.cabal.in - docs/users_guide/exts/multiway_if.rst - docs/users_guide/rtd-theme/layout.html - hadrian/src/Builder.hs - hadrian/src/Rules/Compile.hs - hadrian/src/Settings/Builders/Cc.hs - hadrian/src/Settings/Packages.hs - libraries/base/base.cabal.in - − libraries/base/src/GHC/Desugar.hs - libraries/text - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - + testsuite/tests/ghc-api/TypeMapStringLiteral.hs - testsuite/tests/ghc-api/all.T - 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/numeric/should_compile/T19641.stderr - testsuite/tests/parser/should_fail/RecordDotSyntaxFail8.stderr - + testsuite/tests/parser/should_fail/T26860ppr.hs - + testsuite/tests/parser/should_fail/T26860ppr.stderr - testsuite/tests/parser/should_fail/all.T - + testsuite/tests/simplCore/should_compile/T26548.hs - + testsuite/tests/simplCore/should_compile/T26548.stderr - testsuite/tests/simplCore/should_compile/T26615.stderr - + testsuite/tests/simplCore/should_compile/T26826.hs - testsuite/tests/simplCore/should_compile/all.T - utils/check-exact/ExactPrint.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hoogle.hs - utils/haddock/haddock-api/src/Haddock/Convert.hs - utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs - utils/haddock/haddock-api/src/Haddock/Types.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/073afea64f641d3b05c3f39accfa2f8... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/073afea64f641d3b05c3f39accfa2f8... You're receiving this email because of your account on gitlab.haskell.org.