May 2025 - ghc-commits

[Git][ghc/ghc][master] 2 commits: wasm: mark freeJSVal as INLINE
by Marge Bot (＠marge-bot) 11 May '25

11 May '25

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: eaa8093b by Cheng Shao at 2025-05-11T03:25:28-04:00 wasm: mark freeJSVal as INLINE This patch marks `freeJSVal` as `INLINE` for the wasm backend. I noticed that the `freeJSVal` invocations are not inlined when inspecting STG/Cmm dumps of downstream libraries that use release build of the wasm backend. The performance benefit of inlining here is very modest, but so is the cost anyway; if you are using `freeJSVal` at all then you care about every potential chance to improve performance :) - - - - - eac196df by Cheng Shao at 2025-05-11T03:25:28-04:00 wasm: add zero length fast path for fromJSString This patch adds a zero length fast path for `fromJSString`; when marshaling a zero-length `JSString` we don't need to allocate an empty `ByteArray#` at all. - - - - - 1 changed file: - libraries/ghc-internal/src/GHC/Internal/Wasm/Prim/Types.hs Changes: ===================================== libraries/ghc-internal/src/GHC/Internal/Wasm/Prim/Types.hs ===================================== @@ -147,6 +147,7 @@ data JSVal -- the same 'JSVal', subsequent invocations are no-ops. You are -- strongly recommended to call 'freeJSVal' on short-lived -- intermediate 'JSVal' values for timely release of resources! +{-# INLINE freeJSVal #-} freeJSVal :: JSVal -> IO () freeJSVal v@(JSVal p) = do js_callback_unregister v @@ -183,15 +184,16 @@ newtype JSString -- eagerly once the resulting 'String' is forced, and the argument -- 'JSString' may be explicitly freed if no longer used. fromJSString :: JSString -> String -fromJSString s = unsafeDupablePerformIO $ do - l <- js_stringLength s - fp <- mallocPlainForeignPtrBytes $ l * 3 - withForeignPtr fp $ \buf -> do - l' <- js_encodeInto s buf $ l * 3 - peekCStringLen utf8 (buf, l') +fromJSString s = case js_stringLength s * 3 of + 0 -> "" + max_len -> unsafePerformIO $ do + fptr <- mallocPlainForeignPtrBytes max_len + withForeignPtr fptr $ \ptr -> do + len <- js_encodeInto s ptr max_len + peekCStringLen utf8 (ptr, len) foreign import javascript unsafe "$1.length" - js_stringLength :: JSString -> IO Int + js_stringLength :: JSString -> Int foreign import javascript unsafe "(new TextEncoder()).encodeInto($1, new Uint8Array(__exports.memory.buffer, $2, $3)).written" js_encodeInto :: JSString -> Ptr a -> Int -> IO Int View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7b2d1e6d0319dabe5a19b130744f6b… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7b2d1e6d0319dabe5a19b130744f6b… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][master] Refine `noGivenNewtypeReprEqs` to account for quantified constraints
by Marge Bot (＠marge-bot) 11 May '25

11 May '25

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: 7b2d1e6d by Simon Peyton Jones at 2025-05-11T03:24:47-04:00 Refine `noGivenNewtypeReprEqs` to account for quantified constraints This little MR fixes #26020. We are on the edge of completeness for newtype equalities (that doesn't change) but this MR makes GHC a bit more consistent -- and fixes the bug reported. - - - - - 6 changed files: - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Solver/InertSet.hs - + testsuite/tests/typecheck/should_compile/T26020.hs - + testsuite/tests/typecheck/should_compile/T26020a.hs - + testsuite/tests/typecheck/should_compile/T26020a_help.hs - testsuite/tests/typecheck/should_compile/all.T Changes: ===================================== compiler/GHC/Tc/Solver/Equality.hs ===================================== @@ -1098,7 +1098,7 @@ There are two ways in which decomposing (N ty1) ~r (N ty2) could be incomplete: them. This is done in can_eq_nc. Of course, we can't unwrap if the data constructor isn't in scope. See Note [Unwrap newtypes first]. -* Incompleteness example (EX2): see #24887 +* Incompleteness example (EX2): prioritise Nominal equalities. See #24887 data family D a data instance D Int = MkD1 (D Char) data instance D Bool = MkD2 (D Char) @@ -1116,7 +1116,7 @@ There are two ways in which decomposing (N ty1) ~r (N ty2) could be incomplete: CONCLUSION: prioritise nominal equalites in the work list. See Note [Prioritise equalities] in GHC.Tc.Solver.InertSet. -* Incompleteness example (EX3): available Givens +* Incompleteness example (EX3): check available Givens newtype Nt a = Mk Bool -- NB: a is not used in the RHS, type role Nt representational -- but the user gives it an R role anyway @@ -1134,36 +1134,41 @@ There are two ways in which decomposing (N ty1) ~r (N ty2) could be incomplete: equalities that could later solve it. But what precisely does it mean to say "any Given equalities that could - later solve it"? - - In #22924 we had - [G] f a ~R# a [W] Const (f a) a ~R# Const a a - where Const is an abstract newtype. If we decomposed the newtype, we - could solve. Not-decomposing on the grounds that (f a ~R# a) might turn - into (Const (f a) a ~R# Const a a) seems a bit silly. - - In #22331 we had - [G] N a ~R# N b [W] N b ~R# N a - (where N is abstract so we can't unwrap). Here we really /don't/ want to - decompose, because the /only/ way to solve the Wanted is from that Given - (with a Sym). - - In #22519 we had - [G] a <= b [W] IO Age ~R# IO Int - - (where IO is abstract so we can't unwrap, and newtype Age = Int; and (<=) - is a type-level comparison on Nats). Here we /must/ decompose, despite the - existence of an Irred Given, or we will simply be stuck. (Side note: We - flirted with deep-rewriting of newtypes (see discussion on #22519 and - !9623) but that turned out not to solve #22924, and also makes type - inference loop more often on recursive newtypes.) + later solve it"? It's tricky! + + * In #22924 we had + [G] f a ~R# a [W] Const (f a) a ~R# Const a a + where Const is an abstract newtype. If we decomposed the newtype, we + could solve. Not-decomposing on the grounds that (f a ~R# a) might turn + into (Const (f a) a ~R# Const a a) seems a bit silly. + + * In #22331 we had + [G] N a ~R# N b [W] N b ~R# N a + (where N is abstract so we can't unwrap). Here we really /don't/ want to + decompose, because the /only/ way to solve the Wanted is from that Given + (with a Sym). + + * In #22519 we had + [G] a <= b [W] IO Age ~R# IO Int + + (where IO is abstract so we can't unwrap, and newtype Age = Int; and (<=) + is a type-level comparison on Nats). Here we /must/ decompose, despite the + existence of an Irred Given, or we will simply be stuck. (Side note: We + flirted with deep-rewriting of newtypes (see discussion on #22519 and + !9623) but that turned out not to solve #22924, and also makes type + inference loop more often on recursive newtypes.) + + * In #26020 we had a /quantified/ constraint + forall x. Coercible (N t1) (N t2) + and (roughly) [W] N t1 ~R# N t2 + That quantified constraint can solve the Wanted, so don't decompose! The currently-implemented compromise is this: - - we decompose [W] N s ~R# N t unless there is a [G] N s' ~ N t' - - that is, a Given Irred equality with both sides headed with N. - See the call to noGivenNewtypeReprEqs in canTyConApp. + We decompose [W] N s ~R# N t unless there is + - an Irred [G] N s' ~ N t' + - a quantified [G] forall ... => N s' ~ N t' + that is, a Given equality with both sides headed with N. + See the call to `noGivenNewtypeReprEqs` in `canTyConApp`. This is not perfect. In principle a Given like [G] (a b) ~ (c d), or even just [G] c, could later turn into N s ~ N t. But since the free @@ -1174,7 +1179,7 @@ There are two ways in which decomposing (N ty1) ~r (N ty2) could be incomplete: un-expanded equality superclasses; but only in some very obscure recursive-superclass situations. - Yet another approach (!) is desribed in + Yet another approach (!) is described in Note [Decomposing newtypes a bit more aggressively]. Remember: decomposing Wanteds is always /sound/. This Note is ===================================== compiler/GHC/Tc/Solver/InertSet.hs ===================================== @@ -70,7 +70,7 @@ import GHC.Core.Predicate import qualified GHC.Core.TyCo.Rep as Rep import GHC.Core.TyCon import GHC.Core.Class( classTyCon ) -import GHC.Builtin.Names( eqPrimTyConKey, heqTyConKey, eqTyConKey ) +import GHC.Builtin.Names( eqPrimTyConKey, heqTyConKey, eqTyConKey, coercibleTyConKey ) import GHC.Utils.Misc ( partitionWith ) import GHC.Utils.Outputable import GHC.Utils.Panic @@ -1862,21 +1862,34 @@ isOuterTyVar tclvl tv | otherwise = False -- Coercion variables; doesn't much matter noGivenNewtypeReprEqs :: TyCon -> InertSet -> Bool --- True <=> there is no Irred looking like (N tys1 ~ N tys2) --- See Note [Decomposing newtype equalities] (EX2) in GHC.Tc.Solver.Equality --- This is the only call site. -noGivenNewtypeReprEqs tc inerts - = not (anyBag might_help (inert_irreds (inert_cans inerts))) +-- True <=> there is no Given looking like (N tys1 ~ N tys2) +-- See Note [Decomposing newtype equalities] (EX3) in GHC.Tc.Solver.Equality +noGivenNewtypeReprEqs tc (IS { inert_cans = inerts }) + | IC { inert_irreds = irreds, inert_insts = quant_cts } <- inerts + = not (anyBag might_help_irred irreds || any might_help_qc quant_cts) + -- Look in both inert_irreds /and/ inert_insts (#26020) where - might_help irred - = case classifyPredType (ctEvPred (irredCtEvidence irred)) of - EqPred ReprEq t1 t2 - | Just (tc1,_) <- tcSplitTyConApp_maybe t1 - , tc == tc1 - , Just (tc2,_) <- tcSplitTyConApp_maybe t2 - , tc == tc2 - -> True - _ -> False + might_help_irred (IrredCt { ir_ev = ev }) + | EqPred ReprEq t1 t2 <- classifyPredType (ctEvPred ev) + = headed_by_tc t1 t2 + | otherwise + = False + + might_help_qc (QCI { qci_body = pred }) + | ClassPred cls [_, t1, t2] <- classifyPredType pred + , cls `hasKey` coercibleTyConKey + = headed_by_tc t1 t2 + | otherwise + = False + + headed_by_tc t1 t2 + | Just (tc1,_) <- tcSplitTyConApp_maybe t1 + , tc == tc1 + , Just (tc2,_) <- tcSplitTyConApp_maybe t2 + , tc == tc2 + = True + | otherwise + = False -- | Is it (potentially) loopy to use the first @ct1@ to solve @ct2@? -- ===================================== testsuite/tests/typecheck/should_compile/T26020.hs ===================================== @@ -0,0 +1,17 @@ +{-# LANGUAGE TypeFamilies #-} +{-# LANGUAGE QuantifiedConstraints #-} + +module T26020 where + +import Data.Kind +import Data.Coerce + +class C r where + data T r :: Type -> Type + +-- type family F r +-- data T r i = MkR r (F i) + +coT :: (forall x. Coercible (T r i) (T r o)) + => T r i -> T r o +coT = coerce ===================================== testsuite/tests/typecheck/should_compile/T26020a.hs ===================================== @@ -0,0 +1,9 @@ +{-# LANGUAGE QuantifiedConstraints #-} +module T26020a where + +import T26020a_help( N ) -- Not the MkN constructor +import Data.Coerce + +coT :: (forall x. Coercible (N i) (N o)) + => N i -> N o +coT = coerce ===================================== testsuite/tests/typecheck/should_compile/T26020a_help.hs ===================================== @@ -0,0 +1,7 @@ +{-# LANGUAGE TypeFamilies #-} + +module T26020a_help where + +type family F a +newtype N a = MkN (F a) + ===================================== testsuite/tests/typecheck/should_compile/all.T ===================================== @@ -938,3 +938,5 @@ test('T25266a', normal, compile_fail, ['']) test('T25266b', normal, compile, ['']) test('T25597', normal, compile, ['']) test('T25960', normal, compile, ['']) +test('T26020', normal, compile, ['']) +test('T26020a', [extra_files(['T26020a_help.hs'])], multimod_compile, ['T26020a', '-v0']) View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7b2d1e6d0319dabe5a19b130744f6b5… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7b2d1e6d0319dabe5a19b130744f6b5… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T25974] 14 commits: llvmGen: Fix built-in variable predicate
by Serge S. Gulin (＠gulin.serge) 11 May '25

11 May '25

Serge S. Gulin pushed to branch wip/T25974 at Glasgow Haskell Compiler / GHC Commits: 6e67fa08 by Ben Gamari at 2025-05-08T06:21:21-04:00 llvmGen: Fix built-in variable predicate Previously the predicate to identify LLVM builtin global variables was checking for `$llvm` rather than `@llvm` as it should. - - - - - a9d0a22c by Ben Gamari at 2025-05-08T06:21:22-04:00 llvmGen: Fix linkage of built-in arrays LLVM now insists that built-in arrays use Appending linkage, not Internal. Fixes #25769. - - - - - 9c6d2b1b by sheaf at 2025-05-08T06:22:11-04:00 Use mkTrAppChecked in ds_ev_typeable This change avoids violating the invariant of mkTrApp according to which the argument should not be a fully saturated function type. This ensures we don't return false negatives for type equality involving function types. Fixes #25998 - - - - - 75cadf81 by Ryan Hendrickson at 2025-05-08T06:22:55-04:00 haddock: Preserve indentation in multiline examples Intended for use with :{ :}, but doesn't look for those characters. Any consecutive lines with birdtracks will only have initial whitespace stripped up to the column of the first line. - - - - - fee9b351 by Cheng Shao at 2025-05-08T06:23:36-04:00 ci: re-enable chrome for wasm ghci browser tests Currently only firefox is enabled for wasm ghci browser tests, for some reason testing with chrome works on my machine but gets stuck on gitlab instance runners. This patch re-enables testing with chrome by passing `--no-sandbox`, since chrome sandboxing doesn't work in containers without `--cap-add=SYS_ADMIN`. - - - - - 282df905 by Vladislav Zavialov at 2025-05-09T03:18:25-04:00 Take subordinate 'type' specifiers into account This patch fixes multiple bugs (#22581, #25983, #25984, #25991) in name resolution of subordinate import lists. Bug #22581 ---------- In subordinate import lists, the use of the `type` namespace specifier used to be ignored. For example, this import statement was incorrectly accepted: import Prelude (Bool(type True)) Now it results in an error message: <interactive>:2:17: error: [GHC-51433] In the import of ‘Prelude’: a data type called ‘Bool’ is exported, but its subordinate item ‘True’ is not in the type namespace. Bug #25983 ---------- In subordinate import lists within a `hiding` clause, non-existent items led to a poor warning message with -Wdodgy-imports. Consider: import Prelude hiding (Bool(X)) The warning message for this import statement used to misreport the cause of the problem: <interactive>:3:24: warning: [GHC-56449] [-Wdodgy-imports] In the import of ‘Prelude’: an item called ‘Bool’ is exported, but it is a type. Now the warning message is correct: <interactive>:2:24: warning: [GHC-10237] [-Wdodgy-imports] In the import of ‘Prelude’: a data type called ‘Bool’ is exported, but it does not export any constructors or record fields called ‘X’. Bug #25984 ---------- In subordinate import lists within a `hiding` clause, non-existent items resulted in the entire import declaration being discarded. For example, this program was incorrectly accepted: import Prelude hiding (Bool(True,X)) t = True Now it results in an error message: <interactive>:2:5: error: [GHC-88464] Data constructor not in scope: True Bug #25991 ---------- In subordinate import lists, it was not possible to refer to a class method if there was an associated type of the same name: module M_helper where class C a b where type a # b (#) :: a -> b -> () module M where import M_helper (C((#))) This import declaration failed with: M.hs:2:28: error: [GHC-10237] In the import of ‘M_helper’: an item called ‘C’ is exported, but it does not export any children (constructors, class methods or field names) called ‘#’. Now it is accepted. Summary ------- The changes required to fix these bugs are almost entirely confined to GHC.Rename.Names. Other than that, there is a new error constructor BadImportNonTypeSubordinates with error code [GHC-51433]. Test cases: T22581a T22581b T22581c T22581d T25983a T25983b T25983c T25983d T25983e T25983f T25983g T25984a T25984b T25991a T25991b1 T25991b2 - - - - - 51b0ce8f by Simon Peyton Jones at 2025-05-09T03:19:07-04:00 Slighty improve `dropMisleading` Fix #26105, by upgrading the (horrible, hacky) `dropMisleading` function. This fix makes things a bit better but does not cure the underlying problem. - - - - - 296dbd17 by Serge S. Gulin at 2025-05-11T09:18:08+04:00 Add Wine support - - - - - 95755d24 by Serge S. Gulin at 2025-05-11T09:18:08+04:00 Test build wine! - - - - - 7c427670 by Serge S. Gulin at 2025-05-11T09:18:08+04:00 Put updated clang toolchain into bootstrap compiler's `mingw` folder - - - - - 2a18e433 by Serge S. Gulin at 2025-05-11T09:18:08+04:00 Enable tests for cross-compiled compiler - - - - - a98ab404 by Serge S. Gulin at 2025-05-11T09:18:08+04:00 Update DOCKER_REV - - - - - a0be4d36 by Serge S. Gulin at 2025-05-11T09:18:08+04:00 Copy mingw from boostrap compiler - - - - - b6c4b6a0 by Serge S. Gulin at 2025-05-11T09:18:08+04:00 Remove CROSS_EMULATOR because we are already in Wine, fix `check_msys2_deps` to support cross-target at Windows - - - - - 75 changed files: - .gitignore - .gitlab-ci.yml - .gitlab/ci.sh - .gitlab/generate-ci/gen_ci.hs - .gitlab/jobs.yaml - boot - compiler/GHC/Builtin/Names.hs - compiler/GHC/CmmToLlvm/Base.hs - compiler/GHC/CmmToLlvm/Data.hs - compiler/GHC/HsToCore/Binds.hs - compiler/GHC/Rename/Names.hs - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Errors/Types.hs - compiler/GHC/Tc/Types/Constraint.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Types/Error/Codes.hs - configure.ac - docs/users_guide/9.14.1-notes.rst - docs/users_guide/exts/explicit_namespaces.rst - hadrian/src/Builder.hs - hadrian/src/Rules/BinaryDist.hs - libraries/ghc-internal/src/GHC/Internal/Event/Windows.hsc - m4/find_merge_objects.m4 - m4/fp_setup_windows_toolchain.m4 - testsuite/tests/driver/RecompExports/RecompExports1.stderr - testsuite/tests/driver/RecompExports/RecompExports4.stderr - testsuite/tests/module/T21826.stderr - testsuite/tests/module/mod81.stderr - testsuite/tests/module/mod91.stderr - + testsuite/tests/rename/should_compile/T22581c.hs - + testsuite/tests/rename/should_compile/T22581c_helper.hs - + testsuite/tests/rename/should_compile/T22581d.script - + testsuite/tests/rename/should_compile/T22581d.stdout - + testsuite/tests/rename/should_compile/T25983a.hs - + testsuite/tests/rename/should_compile/T25983a.stderr - + testsuite/tests/rename/should_compile/T25983b.hs - + testsuite/tests/rename/should_compile/T25983b.stderr - + testsuite/tests/rename/should_compile/T25983c.hs - + testsuite/tests/rename/should_compile/T25983c.stderr - + testsuite/tests/rename/should_compile/T25983d.hs - + testsuite/tests/rename/should_compile/T25983d.stderr - + testsuite/tests/rename/should_compile/T25983e.hs - + testsuite/tests/rename/should_compile/T25983e.stderr - + testsuite/tests/rename/should_compile/T25983f.hs - + testsuite/tests/rename/should_compile/T25983f.stderr - + testsuite/tests/rename/should_compile/T25983g.hs - + testsuite/tests/rename/should_compile/T25983g.stderr - + testsuite/tests/rename/should_compile/T25984a.hs - + testsuite/tests/rename/should_compile/T25984a.stderr - + testsuite/tests/rename/should_compile/T25984a_helper.hs - + testsuite/tests/rename/should_compile/T25991a.hs - + testsuite/tests/rename/should_compile/T25991a_helper.hs - testsuite/tests/rename/should_compile/all.T - + testsuite/tests/rename/should_fail/T22581a.hs - + testsuite/tests/rename/should_fail/T22581a.stderr - + testsuite/tests/rename/should_fail/T22581a_helper.hs - + testsuite/tests/rename/should_fail/T22581b.hs - + testsuite/tests/rename/should_fail/T22581b.stderr - + testsuite/tests/rename/should_fail/T22581b_helper.hs - + testsuite/tests/rename/should_fail/T25984b.hs - + testsuite/tests/rename/should_fail/T25984b.stderr - + testsuite/tests/rename/should_fail/T25991b1.hs - + testsuite/tests/rename/should_fail/T25991b1.stderr - + testsuite/tests/rename/should_fail/T25991b2.hs - + testsuite/tests/rename/should_fail/T25991b2.stderr - + testsuite/tests/rename/should_fail/T25991b_helper.hs - testsuite/tests/rename/should_fail/T9006.stderr - testsuite/tests/rename/should_fail/all.T - + testsuite/tests/typecheck/should_fail/T26015.hs - + testsuite/tests/typecheck/should_fail/T26015.stderr - + testsuite/tests/typecheck/should_run/T25998.hs - + testsuite/tests/typecheck/should_run/T25998.stdout - testsuite/tests/typecheck/should_run/all.T - utils/haddock/haddock-library/src/Documentation/Haddock/Parser.hs - utils/haddock/haddock-library/test/Documentation/Haddock/ParserSpec.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0c7c5407d91971f163f4862fbd7580… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0c7c5407d91971f163f4862fbd7580… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: Take subordinate 'type' specifiers into account
by Marge Bot (＠marge-bot) 10 May '25

10 May '25

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: 282df905 by Vladislav Zavialov at 2025-05-09T03:18:25-04:00 Take subordinate 'type' specifiers into account This patch fixes multiple bugs (#22581, #25983, #25984, #25991) in name resolution of subordinate import lists. Bug #22581 ---------- In subordinate import lists, the use of the `type` namespace specifier used to be ignored. For example, this import statement was incorrectly accepted: import Prelude (Bool(type True)) Now it results in an error message: <interactive>:2:17: error: [GHC-51433] In the import of ‘Prelude’: a data type called ‘Bool’ is exported, but its subordinate item ‘True’ is not in the type namespace. Bug #25983 ---------- In subordinate import lists within a `hiding` clause, non-existent items led to a poor warning message with -Wdodgy-imports. Consider: import Prelude hiding (Bool(X)) The warning message for this import statement used to misreport the cause of the problem: <interactive>:3:24: warning: [GHC-56449] [-Wdodgy-imports] In the import of ‘Prelude’: an item called ‘Bool’ is exported, but it is a type. Now the warning message is correct: <interactive>:2:24: warning: [GHC-10237] [-Wdodgy-imports] In the import of ‘Prelude’: a data type called ‘Bool’ is exported, but it does not export any constructors or record fields called ‘X’. Bug #25984 ---------- In subordinate import lists within a `hiding` clause, non-existent items resulted in the entire import declaration being discarded. For example, this program was incorrectly accepted: import Prelude hiding (Bool(True,X)) t = True Now it results in an error message: <interactive>:2:5: error: [GHC-88464] Data constructor not in scope: True Bug #25991 ---------- In subordinate import lists, it was not possible to refer to a class method if there was an associated type of the same name: module M_helper where class C a b where type a # b (#) :: a -> b -> () module M where import M_helper (C((#))) This import declaration failed with: M.hs:2:28: error: [GHC-10237] In the import of ‘M_helper’: an item called ‘C’ is exported, but it does not export any children (constructors, class methods or field names) called ‘#’. Now it is accepted. Summary ------- The changes required to fix these bugs are almost entirely confined to GHC.Rename.Names. Other than that, there is a new error constructor BadImportNonTypeSubordinates with error code [GHC-51433]. Test cases: T22581a T22581b T22581c T22581d T25983a T25983b T25983c T25983d T25983e T25983f T25983g T25984a T25984b T25991a T25991b1 T25991b2 - - - - - 51b0ce8f by Simon Peyton Jones at 2025-05-09T03:19:07-04:00 Slighty improve `dropMisleading` Fix #26105, by upgrading the (horrible, hacky) `dropMisleading` function. This fix makes things a bit better but does not cure the underlying problem. - - - - - 5fb23ed7 by Simon Peyton Jones at 2025-05-10T18:04:16-04:00 Refine `noGivenNewtypeReprEqs` to account for quantified constraints This little MR fixes #26020. We are on the edge of completeness for newtype equalities (that doesn't change) but this MR makes GHC a bit more consistent -- and fixes the bug reported. - - - - - 4fc2c20c by Cheng Shao at 2025-05-10T18:04:17-04:00 wasm: mark freeJSVal as INLINE This patch marks `freeJSVal` as `INLINE` for the wasm backend. I noticed that the `freeJSVal` invocations are not inlined when inspecting STG/Cmm dumps of downstream libraries that use release build of the wasm backend. The performance benefit of inlining here is very modest, but so is the cost anyway; if you are using `freeJSVal` at all then you care about every potential chance to improve performance :) - - - - - 1d75bc7a by Cheng Shao at 2025-05-10T18:04:17-04:00 wasm: add zero length fast path for fromJSString This patch adds a zero length fast path for `fromJSString`; when marshaling a zero-length `JSString` we don't need to allocate an empty `ByteArray#` at all. - - - - - 61 changed files: - compiler/GHC/Rename/Names.hs - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Errors/Types.hs - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Solver/InertSet.hs - compiler/GHC/Tc/Types/Constraint.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Types/Error/Codes.hs - docs/users_guide/9.14.1-notes.rst - docs/users_guide/exts/explicit_namespaces.rst - libraries/ghc-internal/src/GHC/Internal/Wasm/Prim/Types.hs - testsuite/tests/driver/RecompExports/RecompExports1.stderr - testsuite/tests/driver/RecompExports/RecompExports4.stderr - testsuite/tests/module/T21826.stderr - testsuite/tests/module/mod81.stderr - testsuite/tests/module/mod91.stderr - + testsuite/tests/rename/should_compile/T22581c.hs - + testsuite/tests/rename/should_compile/T22581c_helper.hs - + testsuite/tests/rename/should_compile/T22581d.script - + testsuite/tests/rename/should_compile/T22581d.stdout - + testsuite/tests/rename/should_compile/T25983a.hs - + testsuite/tests/rename/should_compile/T25983a.stderr - + testsuite/tests/rename/should_compile/T25983b.hs - + testsuite/tests/rename/should_compile/T25983b.stderr - + testsuite/tests/rename/should_compile/T25983c.hs - + testsuite/tests/rename/should_compile/T25983c.stderr - + testsuite/tests/rename/should_compile/T25983d.hs - + testsuite/tests/rename/should_compile/T25983d.stderr - + testsuite/tests/rename/should_compile/T25983e.hs - + testsuite/tests/rename/should_compile/T25983e.stderr - + testsuite/tests/rename/should_compile/T25983f.hs - + testsuite/tests/rename/should_compile/T25983f.stderr - + testsuite/tests/rename/should_compile/T25983g.hs - + testsuite/tests/rename/should_compile/T25983g.stderr - + testsuite/tests/rename/should_compile/T25984a.hs - + testsuite/tests/rename/should_compile/T25984a.stderr - + testsuite/tests/rename/should_compile/T25984a_helper.hs - + testsuite/tests/rename/should_compile/T25991a.hs - + testsuite/tests/rename/should_compile/T25991a_helper.hs - testsuite/tests/rename/should_compile/all.T - + testsuite/tests/rename/should_fail/T22581a.hs - + testsuite/tests/rename/should_fail/T22581a.stderr - + testsuite/tests/rename/should_fail/T22581a_helper.hs - + testsuite/tests/rename/should_fail/T22581b.hs - + testsuite/tests/rename/should_fail/T22581b.stderr - + testsuite/tests/rename/should_fail/T22581b_helper.hs - + testsuite/tests/rename/should_fail/T25984b.hs - + testsuite/tests/rename/should_fail/T25984b.stderr - + testsuite/tests/rename/should_fail/T25991b1.hs - + testsuite/tests/rename/should_fail/T25991b1.stderr - + testsuite/tests/rename/should_fail/T25991b2.hs - + testsuite/tests/rename/should_fail/T25991b2.stderr - + testsuite/tests/rename/should_fail/T25991b_helper.hs - testsuite/tests/rename/should_fail/T9006.stderr - testsuite/tests/rename/should_fail/all.T - + testsuite/tests/typecheck/should_compile/T26020.hs - + testsuite/tests/typecheck/should_compile/T26020a.hs - + testsuite/tests/typecheck/should_compile/T26020a_help.hs - testsuite/tests/typecheck/should_compile/all.T - + testsuite/tests/typecheck/should_fail/T26015.hs - + testsuite/tests/typecheck/should_fail/T26015.stderr The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d150a3b027eacc3995647153efdc8c… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d150a3b027eacc3995647153efdc8c… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/int-index/data-namespace-specifier
by Vladislav Zavialov (＠int-index) 10 May '25

10 May '25

Vladislav Zavialov pushed new branch wip/int-index/data-namespace-specifier at Glasgow Haskell Compiler / GHC -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/tree/wip/int-index/data-namespace-spec… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T25974] Copy mingw from boostrap compiler
by Serge S. Gulin (＠gulin.serge) 10 May '25

10 May '25

Serge S. Gulin pushed to branch wip/T25974 at Glasgow Haskell Compiler / GHC Commits: 0c7c5407 by Serge S. Gulin at 2025-05-10T18:01:43+04:00 Copy mingw from boostrap compiler - - - - - 2 changed files: - .gitlab/generate-ci/gen_ci.hs - .gitlab/jobs.yaml Changes: ===================================== .gitlab/generate-ci/gen_ci.hs ===================================== @@ -869,6 +869,10 @@ job arch opsys buildConfig = NamedJob { name = jobName, jobInfo = Job {..} } , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh configure" -- We have to trigger cabal build in an independent way to mitigate Wine hangs at MSYS2/Arm64EC , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l -c './hadrian/build-cabal clean'" + -- We use "--enable-distro-toolchain" due of TOOLCHAIN_SOURCE="env", so we have to manually copy + -- bootstrap's compiler mingw into `_build` because binary-dist-dir requires it at Windows. + -- After './hadrian/build-cabal clean' we have to recreate the build root directory. + , "mkdir ./_build && cp -r ~/.wine/drive_c/msys64/opt/ghc-bootstrap/mingw ./_build/" , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh build_hadrian" , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh test_hadrian" ] ===================================== .gitlab/jobs.yaml ===================================== @@ -523,6 +523,7 @@ "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh setup", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh configure", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l -c './hadrian/build-cabal clean'", + "mkdir ./_build && cp -r ~/.wine/drive_c/msys64/opt/ghc-bootstrap/mingw ./_build/", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh build_hadrian", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh test_hadrian" ], @@ -1281,6 +1282,7 @@ "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh setup", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh configure", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l -c './hadrian/build-cabal clean'", + "mkdir ./_build && cp -r ~/.wine/drive_c/msys64/opt/ghc-bootstrap/mingw ./_build/", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh build_hadrian", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh test_hadrian" ], View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/0c7c5407d91971f163f4862fbd75806… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/0c7c5407d91971f163f4862fbd75806… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T25974] Copy mingw from boostrap compiler
by Serge S. Gulin (＠gulin.serge) 10 May '25

10 May '25

Serge S. Gulin pushed to branch wip/T25974 at Glasgow Haskell Compiler / GHC Commits: 815147bf by Serge S. Gulin at 2025-05-10T16:47:11+04:00 Copy mingw from boostrap compiler - - - - - 2 changed files: - .gitlab/generate-ci/gen_ci.hs - .gitlab/jobs.yaml Changes: ===================================== .gitlab/generate-ci/gen_ci.hs ===================================== @@ -869,6 +869,10 @@ job arch opsys buildConfig = NamedJob { name = jobName, jobInfo = Job {..} } , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh configure" -- We have to trigger cabal build in an independent way to mitigate Wine hangs at MSYS2/Arm64EC , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l -c './hadrian/build-cabal clean'" + -- We use "--enable-distro-toolchain" due of TOOLCHAIN_SOURCE="env", so we have to manually copy + -- bootstrap's compiler mingw into `_build` because binary-dist-dir requires it at Windows. + -- After './hadrian/build-cabal clean' we have to recreate the build root directory. + , "mkdir ./_build && cp -r ../.wine/drive_c/msys64/opt/ghc-bootstrap/mingw ./_build/" , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh build_hadrian" , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh test_hadrian" ] ===================================== .gitlab/jobs.yaml ===================================== @@ -523,6 +523,7 @@ "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh setup", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh configure", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l -c './hadrian/build-cabal clean'", + "mkdir ./_build && cp -r ../.wine/drive_c/msys64/opt/ghc-bootstrap/mingw ./_build/", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh build_hadrian", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh test_hadrian" ], @@ -1281,6 +1282,7 @@ "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh setup", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh configure", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l -c './hadrian/build-cabal clean'", + "mkdir ./_build && cp -r ../.wine/drive_c/msys64/opt/ghc-bootstrap/mingw ./_build/", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh build_hadrian", "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh test_hadrian" ], View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/815147bfe36bfe882e5d54b796e3d05… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/815147bfe36bfe882e5d54b796e3d05… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T25974] 2 commits: Update DOCKER_REV
by Serge S. Gulin (＠gulin.serge) 10 May '25

10 May '25

Serge S. Gulin pushed to branch wip/T25974 at Glasgow Haskell Compiler / GHC Commits: b347c867 by Serge S. Gulin at 2025-05-10T01:42:34+04:00 Update DOCKER_REV - - - - - f017540c by Serge S. Gulin at 2025-05-10T12:09:02+04:00 Copy mingw from boostrap compiler - - - - - 2 changed files: - .gitlab-ci.yml - .gitlab/generate-ci/gen_ci.hs Changes: ===================================== .gitlab-ci.yml ===================================== @@ -2,7 +2,7 @@ variables: GIT_SSL_NO_VERIFY: "1" # Commit of ghc/ci-images repository from which to pull Docker images - DOCKER_REV: 3f387f623141bae4c59f4ce235c13561856f6a01 + DOCKER_REV: 719761ba598220b9576f82aab39e442cc1a1cf1f # Sequential version number of all cached things. # Bump to invalidate GitLab CI cache. ===================================== .gitlab/generate-ci/gen_ci.hs ===================================== @@ -869,6 +869,9 @@ job arch opsys buildConfig = NamedJob { name = jobName, jobInfo = Job {..} } , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh configure" -- We have to trigger cabal build in an independent way to mitigate Wine hangs at MSYS2/Arm64EC , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l -c './hadrian/build-cabal clean'" + -- We use "--enable-distro-toolchain" due of TOOLCHAIN_SOURCE="env", so we have to manually copy + -- bootstrap's compiler mingw into `_build` because binary-dist-dir requires it at Windows. + , "cp -r ../.wine/drive_c/msys64/opt/ghc-bootstrap/mingw ./_build/" , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh build_hadrian" , "/opt/wine-arm64ec-msys2-deb12/bin/wine c:/msys64/usr/bin/bash.exe -l .gitlab/ci.sh test_hadrian" ] View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a21cee9058a065da148aaface05039… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a21cee9058a065da148aaface05039… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/fendor/ghci-multiple-home-units] 4 commits: Add testcases for GHCi multiple home units
by Hannes Siebenhandl (＠fendor) 10 May '25

10 May '25

Hannes Siebenhandl pushed to branch wip/fendor/ghci-multiple-home-units at Glasgow Haskell Compiler / GHC Commits: c8b59343 by fendor at 2025-05-10T09:11:35+02:00 Add testcases for GHCi multiple home units Adds the following testcases: * Evaluate code with a single home unit using 'initMulti' initialisation logic * More complicated testcase with multiple home units, testing reload logic and code evaluation. - - - - - 45532dd3 by fendor at 2025-05-10T09:11:35+02:00 FIXME: these test cases can be fixed by exploiting internals - - - - - 254e5347 by fendor at 2025-05-10T09:11:35+02:00 Make GHCi commands compatible with multiple home units === Design We enable all GHCi features that were previously guarded by the `inMulti` option. GHCi supported multiple home units up to a certain degree for quite a while now. The supported feature set was limited, due to a design impasse: One of the home units must be "active", e.g., there must be one `HomeUnit` whose `UnitId` is "active" which is returned when calling ```haskell do hscActiveUnitId <$> getSession ``` This makes sense in a GHC session, since you are always compiling a particular Module, but it makes less intuitive sense in an interactive session. Given an expression to evaluate, we can`t easily tell in which "context" the expression should be parsed, typechecked and evaluated. That`s why initially, most of GHCi features, except for `:reload`ing were disabled if the GHCi session had more than one `HomeUnitEnv`. We lift this restriction, enabling all features of GHCi for the multiple home unit case. To do this, we fundamentally change the `HomeUnitEnv` graph to be multiple home unit first. Instead of differentiating the case were we have a single home unit and multiple, we now always set up a multiple home unit session that scales seamlessly to an arbitrary amount of home units. We introduce two new `HomeUnitEnv`s that are always added to the `HomeUnitGraph`. They are: The "interactive-ghci", called the `interactiveGhciUnit`, contains the same `DynFlags` that are used by the `InteractiveContext` for interactive evaluation of expressions. This `HomeUnitEnv` is only used on the prompt of GHCi, so we may refer to it as "interactive-prompt" unit. See Note [Relation between the `InteractiveContext` and `interactiveGhciUnitId`] for discussing its role. And the `interactive-session`, called `interactiveSessionUnit` or `interactiveSessionUnitId`, which is used for loading Scripts into GHCi that are not `Target`s of any home unit, via `:load` or `:add`. Both of these "interactive" home units depend on all other `HomeUnitEnv`s that are passed as arguments on the cli. Additionally, the "interactive-ghci" unit depends on `interactive-session`. We always evaluate expressions in the context of the "interactive-ghci" session. Since "interactive-ghci" depends on all home units, we can import any `Module` from the other home units with ease. As we have a clear `HomeUnitGraph` hierarchy, we can set `interactiveGhciUnitId` as the active home unit for the full duration of the GHCi session. In GHCi, we always set `interactiveGhciUnitId` to be the currently active home unit. === Implementation Details Given this design idea, the implementation is relatively straight forward. The core insight is that a `ModuleName` is not sufficient to identify a `Module` in the `HomeUnitGraph`. Thus, large parts of the PR is simply about refactoring usages of `ModuleName` to prefer `Module`, which has a `Unit` attached and is unique over the `HomeUnitGraph`. Consequentially, most usages of `lookupHPT` are likely to be incorrect and have been replaced by `lookupHugByModule` which is keyed by a `Module`. In GHCi/UI.hs, we make sure there is only one location where we are actually translating `ModuleName` to a `Module`: * `lookupQualifiedModuleName` If a `ModuleName` is ambiguous, we detect this and report it to the user. To avoid repeated lookups of `ModuleName`s, we store the `Module` in the `InteractiveImport`, which additionally simplifies the interface loading. A subtle detail is that the `DynFlags` of the `InteractiveContext` are now stored both in the `HomeUnitGraph` and in the `InteractiveContext`. In UI.hs, there are multiple code paths where we are careful to update the `DynFlags` in both locations. Most importantly in `addToProgramDynFlags`. --- There is one metric increase in this commit: ------------------------- Metric Increase: T4029 ------------------------- It is an increase from 14.4 MB to 16.1 MB (+11.8%) which sounds like a pretty big regression at first. However, we argue this increase is solely caused by using more data structures for managing multiple home units in the GHCi session. In particular, due to the design decision of using three home units, the base memory usage increases... but by how much? A big contributor is the `UnitState`, of which we have three now, which on its own 260 KB per instance. That makes an additional memory usage of 520 KB, already explaining a third of the overall memory usage increase. Then we store more elements in the `HomeUnitGraph`, we have more `HomeUnitEnv` entries, etc... While we didn't chase down each byte, we looked at the memory usage over time for both `-hi` and `-hT` profiles and can say with confidence while the memory usage increased slightly, we did not introduce any space leak, as the graph looks almost identical as the memory usage graph of GHC HEAD. - - - - - 9fac094b by fendor at 2025-05-10T09:11:35+02:00 FIXUP: Multiple Home Units is no longer a special case - - - - - 125 changed files: - compiler/GHC.hs - compiler/GHC/Driver/Downsweep.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/Iface/Load.hs - compiler/GHC/Rename/Unbound.hs - compiler/GHC/Runtime/Context.hs - compiler/GHC/Runtime/Eval.hs - compiler/GHC/StgToByteCode.hs - compiler/GHC/StgToJS/Linker/Linker.hs - compiler/GHC/Tc/Module.hs - compiler/GHC/Types/Name/Ppr.hs - compiler/GHC/Unit/Env.hs - compiler/GHC/Unit/Home/Graph.hs - compiler/GHC/Unit/Types.hs - ghc/GHCi/UI.hs - ghc/GHCi/UI/Exception.hs - ghc/GHCi/UI/Info.hs - ghc/GHCi/UI/Monad.hs - ghc/Main.hs - testsuite/driver/testlib.py - testsuite/tests/backpack/cabal/bkpcabal08/bkpcabal08.stdout - testsuite/tests/driver/T8526/T8526.stdout - testsuite/tests/driver/fat-iface/fat014.stdout - testsuite/tests/driver/multipleHomeUnits/multiGHCi.stderr - testsuite/tests/ghc-api/T6145.hs - testsuite/tests/ghc-api/annotations-literals/literals.hs - testsuite/tests/ghc-api/annotations-literals/parsed.hs - testsuite/tests/ghc-api/apirecomp001/myghc.hs - testsuite/tests/ghc-api/fixed-nodes/T1.hs - + testsuite/tests/ghci.debugger/scripts/break031/Makefile - + testsuite/tests/ghci.debugger/scripts/break031/a/A.hs - + testsuite/tests/ghci.debugger/scripts/break031/all.T - + testsuite/tests/ghci.debugger/scripts/break031/b/B.hs - + testsuite/tests/ghci.debugger/scripts/break031/break031a.script - + testsuite/tests/ghci.debugger/scripts/break031/break031a.stdout - + testsuite/tests/ghci.debugger/scripts/break031/break031b.script - + testsuite/tests/ghci.debugger/scripts/break031/break031b.stderr - + testsuite/tests/ghci.debugger/scripts/break031/break031b.stdout - + testsuite/tests/ghci.debugger/scripts/break031/unitA - + testsuite/tests/ghci.debugger/scripts/break031/unitB - testsuite/tests/ghci/linking/dyn/T3372.hs - + testsuite/tests/ghci/prog-mhu001/Makefile - + testsuite/tests/ghci/prog-mhu001/all.T - + testsuite/tests/ghci/prog-mhu001/e/E.hs - + testsuite/tests/ghci/prog-mhu001/prog-mhu001a.script - + testsuite/tests/ghci/prog-mhu001/prog-mhu001a.stdout - + testsuite/tests/ghci/prog-mhu001/prog-mhu001b.script - + testsuite/tests/ghci/prog-mhu001/prog-mhu001b.stdout - + testsuite/tests/ghci/prog-mhu001/prog-mhu001c.script - + testsuite/tests/ghci/prog-mhu001/prog-mhu001c.stdout - + testsuite/tests/ghci/prog-mhu001/prog-mhu001d.script - + testsuite/tests/ghci/prog-mhu001/prog-mhu001d.stdout - + testsuite/tests/ghci/prog-mhu001/prog-mhu001e.script - + testsuite/tests/ghci/prog-mhu001/prog-mhu001e.stdout - + testsuite/tests/ghci/prog-mhu001/prog-mhu001f.script - + testsuite/tests/ghci/prog-mhu001/prog-mhu001f.stdout - + testsuite/tests/ghci/prog-mhu001/unitE - + testsuite/tests/ghci/prog-mhu001/unitE-main-is - + testsuite/tests/ghci/prog-mhu002/Makefile - + testsuite/tests/ghci/prog-mhu002/a/A.hs - + testsuite/tests/ghci/prog-mhu002/all.T - + testsuite/tests/ghci/prog-mhu002/b/B.hs - + testsuite/tests/ghci/prog-mhu002/c/C.hs - + testsuite/tests/ghci/prog-mhu002/d/Main.hs - + testsuite/tests/ghci/prog-mhu002/prog-mhu002a.script - + testsuite/tests/ghci/prog-mhu002/prog-mhu002a.stderr - + testsuite/tests/ghci/prog-mhu002/prog-mhu002a.stdout - + testsuite/tests/ghci/prog-mhu002/prog-mhu002b.script - + testsuite/tests/ghci/prog-mhu002/prog-mhu002b.stderr - + testsuite/tests/ghci/prog-mhu002/prog-mhu002b.stdout - + testsuite/tests/ghci/prog-mhu002/prog-mhu002c.script - + testsuite/tests/ghci/prog-mhu002/prog-mhu002c.stdout - + testsuite/tests/ghci/prog-mhu002/prog-mhu002d.script - + testsuite/tests/ghci/prog-mhu002/prog-mhu002d.stdout - + testsuite/tests/ghci/prog-mhu002/prog-mhu002e.script - + testsuite/tests/ghci/prog-mhu002/prog-mhu002e.stdout - + testsuite/tests/ghci/prog-mhu002/prog-mhu002f.script - + testsuite/tests/ghci/prog-mhu002/prog-mhu002f.stdout - + testsuite/tests/ghci/prog-mhu002/unitA - + testsuite/tests/ghci/prog-mhu002/unitB - + testsuite/tests/ghci/prog-mhu002/unitC - + testsuite/tests/ghci/prog-mhu002/unitD - + testsuite/tests/ghci/prog-mhu003/Makefile - + testsuite/tests/ghci/prog-mhu003/a/A.hs - + testsuite/tests/ghci/prog-mhu003/all.T - + testsuite/tests/ghci/prog-mhu003/b/Foo.hs - + testsuite/tests/ghci/prog-mhu003/c/C.hs - + testsuite/tests/ghci/prog-mhu003/d/Foo.hs - + testsuite/tests/ghci/prog-mhu003/prog-mhu003.script - + testsuite/tests/ghci/prog-mhu003/prog-mhu003.stderr - + testsuite/tests/ghci/prog-mhu003/prog-mhu003.stdout - + testsuite/tests/ghci/prog-mhu003/unitA - + testsuite/tests/ghci/prog-mhu003/unitB - + testsuite/tests/ghci/prog-mhu003/unitC - + testsuite/tests/ghci/prog-mhu003/unitD - + testsuite/tests/ghci/prog-mhu004/Makefile - + testsuite/tests/ghci/prog-mhu004/a/Foo.hs - + testsuite/tests/ghci/prog-mhu004/all.T - + testsuite/tests/ghci/prog-mhu004/b/Foo.hs - + testsuite/tests/ghci/prog-mhu004/prog-mhu004a.script - + testsuite/tests/ghci/prog-mhu004/prog-mhu004a.stderr - + testsuite/tests/ghci/prog-mhu004/prog-mhu004a.stdout - + testsuite/tests/ghci/prog-mhu004/prog-mhu004b.script - + testsuite/tests/ghci/prog-mhu004/prog-mhu004b.stdout - + testsuite/tests/ghci/prog-mhu004/unitA - + testsuite/tests/ghci/prog-mhu004/unitB - testsuite/tests/ghci/prog010/ghci.prog010.script - testsuite/tests/ghci/prog018/prog018.stdout - testsuite/tests/ghci/scripts/T13869.stdout - testsuite/tests/ghci/scripts/T13997.stdout - testsuite/tests/ghci/scripts/T17669.stdout - testsuite/tests/ghci/scripts/T18330.stdout - testsuite/tests/ghci/scripts/T1914.stdout - testsuite/tests/ghci/scripts/T20217.stdout - testsuite/tests/ghci/scripts/T20587.stdout - testsuite/tests/ghci/scripts/T21110.stderr - testsuite/tests/ghci/scripts/T6105.stdout - testsuite/tests/ghci/scripts/T8042.stdout - testsuite/tests/ghci/scripts/T8042recomp.stdout - testsuite/tests/ghci/scripts/ghci024.stdout - testsuite/tests/ghci/scripts/ghci024.stdout-mingw32 - testsuite/tests/ghci/scripts/ghci058.script - testsuite/tests/ghci/should_run/TopEnvIface.stdout - testsuite/tests/linters/notes.stdout - testsuite/tests/quasiquotation/T7918.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/798408f3db0fcdd2198b4eea07511e… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/798408f3db0fcdd2198b4eea07511e… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/wasm-minor-improvements] wasm: add zero length fast path for fromJSString
by Cheng Shao (＠TerrorJack) 09 May '25

09 May '25

Cheng Shao pushed to branch wip/wasm-minor-improvements at Glasgow Haskell Compiler / GHC Commits: f098a7b5 by Cheng Shao at 2025-05-09T21:24:20+00:00 wasm: add zero length fast path for fromJSString This patch adds a zero length fast path for `fromJSString`; when marshaling a zero-length `JSString` we don't need to allocate an empty `ByteArray#` at all. - - - - - 1 changed file: - libraries/ghc-internal/src/GHC/Internal/Wasm/Prim/Types.hs Changes: ===================================== libraries/ghc-internal/src/GHC/Internal/Wasm/Prim/Types.hs ===================================== @@ -184,15 +184,16 @@ newtype JSString -- eagerly once the resulting 'String' is forced, and the argument -- 'JSString' may be explicitly freed if no longer used. fromJSString :: JSString -> String -fromJSString s = unsafeDupablePerformIO $ do - l <- js_stringLength s - fp <- mallocPlainForeignPtrBytes $ l * 3 - withForeignPtr fp $ \buf -> do - l' <- js_encodeInto s buf $ l * 3 - peekCStringLen utf8 (buf, l') +fromJSString s = case js_stringLength s * 3 of + 0 -> "" + max_len -> unsafePerformIO $ do + fptr <- mallocPlainForeignPtrBytes max_len + withForeignPtr fptr $ \ptr -> do + len <- js_encodeInto s ptr max_len + peekCStringLen utf8 (ptr, len) foreign import javascript unsafe "$1.length" - js_stringLength :: JSString -> IO Int + js_stringLength :: JSString -> Int foreign import javascript unsafe "(new TextEncoder()).encodeInto($1, new Uint8Array(__exports.memory.buffer, $2, $3)).written" js_encodeInto :: JSString -> Ptr a -> Int -> IO Int View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/f098a7b5d1d8c9678a4f5267b2265bd… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/f098a7b5d1d8c9678a4f5267b2265bd… You're receiving this email because of your account on gitlab.haskell.org.

1 0