Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: b19fcc1c by Vladislav Zavialov at 2026-08-14T06:26:11-04:00 Increase test coverage of diagnostics, batch 2 Add test cases for the previously untested diagnostics: [GHC-26133] TcRnForeignImportPrimSafeAnn [GHC-68444] SumAltArityExceeded [GHC-63966] IllegalSumAlt [GHC-23882] IllegalDeclaration [GHC-60220] InvalidCCallImpent [GHC-18816] RecGadtNoCons [GHC-38140] GadtNoCons [GHC-37056] InvalidTypeInstanceHeader [GHC-78486] InvalidTyFamInstLHS [GHC-39639] DefaultDataInstDecl [GHC-78822] AssocDefaultNotAssoc [GHC-43510] NotSimpleUnliftedType [GHC-41843] IOResultExpected [GHC-07641] AtLeastOneArgExpected [GHC-52886] InvalidTopDecl Remove unused error constructors: [GHC-92057] ImportLookupAmbiguous - - - - - 7b27f25a by Simon Jakobi at 2026-08-14T06:26:54-04:00 testsuite: Drop peak_megabytes_allocated from LinkableUsage tests LinkableUsage01/02 collected all metrics with a 2% tolerance. For peak_megabytes_allocated, whose granularity is 1 MB, that window is under 0.7 MB at this test's ~34 MB peak, so any 1 MB step failed the test (#27613, #27489). Drop that metric: max_bytes_used guards the Linkable-retention property with byte granularity, at a tolerance that still comfortably exceeds the noise observed in CI. Assisted-by: Claude Fable 5 - - - - - e5de423b by Simon Jakobi at 2026-08-14T06:26:54-04:00 testsuite: Don't truncate fractional baselines when computing bounds RelativeMetricAcceptanceWindow.get_bounds truncated the baseline with int() before applying the tolerance. Baselines can be fractional (they are averaged over several measurements), so this skewed the acceptance window downwards: in #27613, a baseline of 33.67 at 2% tolerance yielded bounds (32, 34) instead of (32, 35), rejecting a measurement that was within tolerance. Assisted-by: Claude Fable 5 - - - - - 83f98e88 by Simon Jakobi at 2026-08-14T11:36:20-04:00 testsuite: Expect length001 failure in nonmoving_thr_sanity length001 relies on an optimization rule to avoid excessive stack use. The nonmoving_thr_sanity way does not enable optimization, so classify its stack overflow as an expected failure, as is already done for the other unoptimized nonmoving ways. Assisted-by: gpt-5.6-sol via Codex CLI - - - - - c49c7afc by Simon Jakobi at 2026-08-14T11:36:20-04:00 testsuite: Omit T22859 in nonmoving threaded ways T22859 checks allocation-limit handlers with output that depends on precise allocation behaviour. The nonmoving threaded ways change where these limits are reached, just as the already-omitted LLVM ways do. Omit these ways instead of treating their incidental output differences as test failures. Assisted-by: gpt-5.6-sol via Codex CLI - - - - - 015900a9 by Simon Jakobi at 2026-08-14T11:36:20-04:00 rts/js: Implement eq_thread, and test Eq/Ord ThreadId (#16761) Since d1f3c63701, Eq ThreadId is implemented via the RTS function eq_thread, but the JS RTS never provided it, so comparing ThreadIds for equality on the JS backend crashed with ReferenceError: h$eq_thread is not defined Like the C implementation, h$eq_thread uses pointer equality: The JS RTS has exactly one thread object per thread. Since previously no test exercised eq_thread directly, this commit adds a test covering equality, its stability across GC, and agreement with Ord. Assisted-by: Claude Fable 5 - - - - - 2a12d702 by Simon Jakobi at 2026-08-14T11:36:20-04:00 testsuite: Make listThreads1 insensitive to the RTS's own threads listThreads1 expected `listThreads` to return exactly [ThreadId 1]. That holds only under a non-threaded RTS. Under a threaded RTS however there are more threads present, so we change the test to simply check that `myThreadId` is present in the list. Assisted-by: Claude Opus 5 - - - - - 418e821b by Vladislav Zavialov at 2026-08-14T11:36:28-04:00 Fix tcLookupId panic with RequiredTypeArguments and PatternSynonyms (#27586) The arguments declared on the left-hand side of a pattern synonym are looked up as term variables bound by its right-hand side. Prior to this patch, that lookup panicked with RequiredTypeArguments: data T a where MkT :: forall a -> T a pattern P :: Int -> T Int pattern P x = MkT x On the RHS, `x` looks like a term argument, so the renamer binds it in the term namespace. Only during type checking does it turn out to be a type variable, so the lookup on the LHS finds an ATyVar rather than an ATcId. As the lookup was done with tcLookupId, it resulted in a panic. Now the arguments are looked up with tcLookupPatSynArg, which reports an illegal term-level use of `x`, just as an ordinary function definition `f (MkT x) = x` does. Test cases: T27586a T27586b T27586c Assisted-by: Claude Opus 5 - - - - - 55 changed files: - + changelog.d/T27586 - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Errors/Types.hs - compiler/GHC/Tc/TyCl/PatSyn.hs - compiler/GHC/Types/Error/Codes.hs - libraries/base/tests/all.T - libraries/base/tests/listThreads1.hs - libraries/base/tests/listThreads1.stdout - rts/js/thread.js - testsuite/driver/perf_notes.py - testsuite/tests/bytecode/TLinkable/all.T - + testsuite/tests/concurrent/should_run/T16761.hs - + testsuite/tests/concurrent/should_run/T16761.stdout - testsuite/tests/concurrent/should_run/all.T - testsuite/tests/diagnostic-codes/codes.stdout - testsuite/tests/ffi/should_fail/all.T - + testsuite/tests/ffi/should_fail/ccfail006.hs - + testsuite/tests/ffi/should_fail/ccfail006.stderr - + testsuite/tests/ffi/should_fail/ccfail007.hs - + testsuite/tests/ffi/should_fail/ccfail007.stderr - + testsuite/tests/ffi/should_fail/ccfail008.hs - + testsuite/tests/ffi/should_fail/ccfail008.stderr - + testsuite/tests/ffi/should_fail/ccfail009.hs - + testsuite/tests/ffi/should_fail/ccfail009.stderr - testsuite/tests/rts/all.T - + testsuite/tests/th/AssocDefaultNotAssoc.hs - + testsuite/tests/th/AssocDefaultNotAssoc.stderr - + testsuite/tests/th/TH_InvalidTopDecl.hs - + testsuite/tests/th/TH_InvalidTopDecl.stderr - + testsuite/tests/th/TH_cvt_DefaultDataInstDecl.hs - + testsuite/tests/th/TH_cvt_DefaultDataInstDecl.stderr - + testsuite/tests/th/TH_cvt_GadtNoCons.hs - + testsuite/tests/th/TH_cvt_GadtNoCons.stderr - + testsuite/tests/th/TH_cvt_IllegalDeclaration.hs - + testsuite/tests/th/TH_cvt_IllegalDeclaration.stderr - + testsuite/tests/th/TH_cvt_IllegalSumAlt.hs - + testsuite/tests/th/TH_cvt_IllegalSumAlt.stderr - + testsuite/tests/th/TH_cvt_InvalidCCallImpent.hs - + testsuite/tests/th/TH_cvt_InvalidCCallImpent.stderr - + testsuite/tests/th/TH_cvt_InvalidTyFamInstLHS.hs - + testsuite/tests/th/TH_cvt_InvalidTyFamInstLHS.stderr - + testsuite/tests/th/TH_cvt_InvalidTypeInstanceHeader.hs - + testsuite/tests/th/TH_cvt_InvalidTypeInstanceHeader.stderr - + testsuite/tests/th/TH_cvt_RecGadtNoCons.hs - + testsuite/tests/th/TH_cvt_RecGadtNoCons.stderr - + testsuite/tests/th/TH_cvt_SumAltArityExceeded.hs - + testsuite/tests/th/TH_cvt_SumAltArityExceeded.stderr - testsuite/tests/th/all.T - + testsuite/tests/vdq-rta/should_fail/T27586a.hs - + testsuite/tests/vdq-rta/should_fail/T27586a.stderr - + testsuite/tests/vdq-rta/should_fail/T27586b.hs - + testsuite/tests/vdq-rta/should_fail/T27586b.stderr - + testsuite/tests/vdq-rta/should_fail/T27586c.hs - + testsuite/tests/vdq-rta/should_fail/T27586c.stderr - testsuite/tests/vdq-rta/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/1acd10f4e72cbb40f8c81172aaf65f6... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/1acd10f4e72cbb40f8c81172aaf65f6... You're receiving this email because of your account on gitlab.haskell.org. Manage all notifications: https://gitlab.haskell.org/-/profile/notifications | Help: https://gitlab.haskell.org/help