Update Trac ticket URLs to point to GitLab

This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.

HACKING.md

@@ -8,9 +8,9 @@ information to help you get started right away.
 The GHC Developer's Wiki
 ========================
 
-The home for GHC hackers is our Trac instance, located here:
+The home for GHC hackers is our GitLab instance, located here:
 
-<http://ghc.haskell.org/trac/ghc>
+<https://gitlab.haskell.org/ghc/ghc>
 
 From here, you can file bugs (or look them up,) use the wiki, view the
 `git` history, among other things. Of particular note is the building
@@ -64,8 +64,8 @@ Now, hack on your copy and rebuild (with `make`) as necessary.
 Then start by making your commits however you want. When you're done, you can submit
  a pull request on Github for small changes. For larger changes the patch needs to be
  submitted to [Phabricator](https://phabricator.haskell.org/) for code review.
- The GHC Trac Wiki has a good summary for the [overall process](https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs)
- as well as a guide on 
+ The GHC Wiki has a good summary for the [overall process](https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs)
+ as well as a guide on
  [how to use Phabricator/arcanist](https://ghc.haskell.org/trac/ghc/wiki/Phabricator).
 
 

Makefile

@@ -22,7 +22,7 @@ MAKEFLAGS += --no-builtin-rules
 # -----------------------------------------------------------------------------
 # Sanitize environment
 
-# See Trac #11530
+# See #11530
 export GREP_OPTIONS :=
 
 ifneq "$(filter maintainer-clean distclean clean clean_% help,$(MAKECMDGOALS))" ""

README.md

@@ -8,7 +8,7 @@ environment for the Haskell functional programming language.
 
 For more information, visit [GHC's web site][1].
 
-Information for developers of GHC can be found on the [GHC Trac][2].
+Information for developers of GHC can be found on the [GHC issue tracker][2].
 
 
 Getting the Source

aclocal.m4

@@ -1483,7 +1483,7 @@ AC_SUBST([GhcPkgCmd])
 # to compile .hc code.
 #
 # -fwrapv is needed for gcc to emit well-behaved code in the presence of
-# integer wrap around. (Trac #952)
+# integer wrap around. (#952)
 #
 AC_DEFUN([FP_GCC_EXTRA_FLAGS],
 [AC_REQUIRE([FP_GCC_VERSION])

compiler/basicTypes/Demand.hs

@@ -124,7 +124,7 @@ mkJointDmds ss as = zipWithEqual "mkJointDmds" mkJointDmd ss as
 Note [Exceptions and strictness]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 We used to smart about catching exceptions, but we aren't anymore.
-See Trac #14998 for the way it's resolved at the moment.
+See #14998 for the way it's resolved at the moment.
 
 Here's a historic breakdown:
 
@@ -138,17 +138,17 @@ their argument, which is useful information for usage analysis. Still with a
 
 In 7c0fff4 (July 15), Simon argued that giving `catch#` et al. a
 'strictApply1Dmd' leads to substantial performance gains. That was at the cost
-of correctness, as Trac #10712 proved. So, back to 'lazyApply1Dmd' in
+of correctness, as #10712 proved. So, back to 'lazyApply1Dmd' in
 28638dfe79e (Dec 15).
 
-Motivated to reproduce the gains of 7c0fff4 without the breakage of Trac #10712,
-Ben opened Trac #11222. Simon made the demand analyser "understand catch" in
+Motivated to reproduce the gains of 7c0fff4 without the breakage of #10712,
+Ben opened #11222. Simon made the demand analyser "understand catch" in
 9915b656 (Jan 16) by adding a new 'catchArgDmd', which basically said to call
 its argument strictly, but also swallow any thrown exceptions in
 'postProcessDmdResult'. This was realized by extending the 'Str' constructor of
 'ArgStr' with a 'ExnStr' field, indicating that it catches the exception, and
 adding a 'ThrowsExn' constructor to the 'Termination' lattice as an element
-between 'Dunno' and 'Diverges'. Then along came Trac #11555 and finally #13330,
+between 'Dunno' and 'Diverges'. Then along came #11555 and finally #13330,
 so we had to revert to 'lazyApply1Dmd' again in 701256df88c (Mar 17).
 
 This left the other variants like 'catchRetry#' having 'catchArgDmd', which is
@@ -159,10 +159,10 @@ there was none. We removed the last usages of 'catchArgDmd' in 00b8ecb7
 removed in ef6b283 (Jan 19): We got rid of 'ThrowsExn' and 'ExnStr' again and
 removed any code that was dealing with the peculiarities.
 
-Where did the speed-ups vanish to? In Trac #14998, item 3 established that
+Where did the speed-ups vanish to? In #14998, item 3 established that
 turning 'catch#' strict in its first argument didn't bring back any of the
 alleged performance benefits. Item 2 of that ticket finally found out that it
-was entirely due to 'catchException's new (since Trac #11555) definition, which
+was entirely due to 'catchException's new (since #11555) definition, which
 was simply
 
     catchException !io handler = catch io handler
@@ -312,7 +312,7 @@ splitStrProdDmd n (SProd ds) = WARN( not (ds `lengthIs` n),
                                Just ds
 splitStrProdDmd _ (SCall {}) = Nothing
       -- This can happen when the programmer uses unsafeCoerce,
-      -- and we don't then want to crash the compiler (Trac #9208)
+      -- and we don't then want to crash the compiler (#9208)
 
 {-
 ************************************************************************
@@ -482,7 +482,7 @@ addCaseBndrDmd (JD { sd = ms, ud = mu }) alt_dmds
 The demand on a binder in a case alternative comes
   (a) From the demand on the binder itself
   (b) From the demand on the case binder
-Forgetting (b) led directly to Trac #10148.
+Forgetting (b) led directly to #10148.
 
 Example. Source code:
   f x@(p,_) = if p then foo x else True
@@ -500,7 +500,7 @@ After strictness analysis:
         True -> foo wild_X7 }
 
 It's true that ds_dnz is *itself* absent, but the use of wild_X7 means
-that it is very much alive and demanded.  See Trac #10148 for how the
+that it is very much alive and demanded.  See #10148 for how the
 consequences play out.
 
 This is needed even for non-product types, in case the case-binder
@@ -603,7 +603,7 @@ splitUseProdDmd n (UProd ds)  = WARN( not (ds `lengthIs` n),
                                 Just ds
 splitUseProdDmd _ (UCall _ _) = Nothing
       -- This can happen when the programmer uses unsafeCoerce,
-      -- and we don't then want to crash the compiler (Trac #9208)
+      -- and we don't then want to crash the compiler (#9208)
 
 useCount :: Use u -> Count
 useCount Abs         = One
@@ -627,7 +627,7 @@ isStrictDmd returns true only of demands that are
    both strict
    and  used
 In particular, it is False for <HyperStr, Abs>, which can and does
-arise in, say (Trac #7319)
+arise in, say (#7319)
    f x = raise# <some exception>
 Then 'x' is not used, so f gets strictness <HyperStr,Abs> -> .
 Now the w/w generates
@@ -637,7 +637,7 @@ At this point we really don't want to convert to
    fx = case absentError "unused" of x -> raise <some exception>
 Since the program is going to diverge, this swaps one error for another,
 but it's really a bad idea to *ever* evaluate an absent argument.
-In Trac #7319 we get
+In #7319 we get
    T7319.exe: Oops!  Entered absent arg w_s1Hd{v} [lid] [base:GHC.Base.String{tc 36u}]
 
 Note [Dealing with call demands]
@@ -844,7 +844,7 @@ Consider this:
 where A,B are the constructors of a GADT.  We'll get a U(U,U) demand
 on x from the A branch, but that's a stupid demand for x itself, which
 has type 'a'. Indeed we get ASSERTs going off (notably in
-splitUseProdDmd, Trac #8569).
+splitUseProdDmd, #8569).
 
 Bottom line: we really don't want to have a binder whose demand is more
 deeply-nested than its type.  There are various ways to tackle this.
@@ -1501,7 +1501,7 @@ There are several wrinkles:
 
 * In a previous incarnation of GHC we needed to be extra careful in the
   case of an *unlifted type*, because unlifted values are evaluated
-  even if they are not used.  Example (see Trac #9254):
+  even if they are not used.  Example (see #9254):
      f :: (() -> (# Int#, () #)) -> ()
           -- Strictness signature is
           --    <C(S(LS)), 1*C1(U(A,1*U()))>
@@ -1696,7 +1696,7 @@ That's fine: if we are doing strictness analysis we are also doing inlining,
 so we'll have inlined 'op' into a cast.  So we can bale out in a conservative
 way, returning nopDmdType.
 
-It is (just.. Trac #8329) possible to be running strictness analysis *without*
+It is (just.. #8329) possible to be running strictness analysis *without*
 having inlined class ops from single-method classes.  Suppose you are using
 ghc --make; and the first module has a local -O0 flag.  So you may load a class
 without interface pragmas, ie (currently) without an unfolding for the class

compiler/basicTypes/Id.hs

@@ -386,7 +386,7 @@ of reasons:
  * Look them up in the current substitution when we come across
    occurrences of them (in Subst.lookupIdSubst). Lacking this we
    can get an out-of-date unfolding, which can in turn make the
-   simplifier go into an infinite loop (Trac #9857)
+   simplifier go into an infinite loop (#9857)
 
  * Ensure that for dfuns that the specialiser does not float dict uses
    above their defns, which would prevent good simplifications happening.
@@ -560,7 +560,7 @@ un-saturated.  Example:
 
 This has a compulsory unfolding because we can't lambda-bind those
 arguments.  But the compulsory unfolding may leave levity-polymorphic
-lambdas if it is not applied to enough arguments; e.g. (Trac #14561)
+lambdas if it is not applied to enough arguments; e.g. (#14561)
   bad :: forall (a :: TYPE r). a -> a
   bad = unsafeCoerce#
 
@@ -569,7 +569,7 @@ And we want that magic to apply to levity-polymorphic compulsory-inline things.
 The easiest way to do this is for hasNoBinding to return True of all things
 that have compulsory unfolding.  A very Ids with a compulsory unfolding also
 have a binding, but it does not harm to say they don't here, and its a very
-simple way to fix Trac #14561.
+simple way to fix #14561.
 
 Note [Primop wrappers]
 ~~~~~~~~~~~~~~~~~~~~~~
@@ -942,7 +942,7 @@ where the '*' means 'LoopBreaker'.  Then if we float we must get
 
 where g' is also marked as LoopBreaker.  If not, terrible things
 can happen if we re-simplify the binding (and the Simplifier does
-sometimes simplify a term twice); see Trac #4345.
+sometimes simplify a term twice); see #4345.
 
 It's not so simple to retain
   * worker info

compiler/basicTypes/Lexeme.hs

@@ -159,9 +159,9 @@ okConIdOcc str = okIdOcc str ||
                  is_tuple_name1 True  str ||
                    -- Is it a boxed tuple...
                  is_tuple_name1 False str ||
-                   -- ...or an unboxed tuple (Trac #12407)...
+                   -- ...or an unboxed tuple (#12407)...
                  is_sum_name1 str
-                   -- ...or an unboxed sum (Trac #12514)?
+                   -- ...or an unboxed sum (#12514)?
   where
     -- check for tuple name, starting at the beginning
     is_tuple_name1 True  ('(' : rest)       = is_tuple_name2 True  rest

compiler/basicTypes/MkId.hs

@@ -746,7 +746,7 @@ constructor has no wrapper, but whether a constructor has a wrapper depends, for
 instance, on the order of type argument of that constructors. Therefore changing
 the order of type argument could make previously working RULEs fail.
 
-See also https://ghc.haskell.org/trac/ghc/ticket/15840 .
+See also https://gitlab.haskell.org/ghc/ghc/issues/15840 .
 
 
 Note [Bangs on imported data constructors]
@@ -778,7 +778,7 @@ We certainly do not want to make a wrapper
 For a start, it's still to generate a no-op.  But worse, since wrappers
 are currently injected at TidyCore, we don't even optimise it away!
 So the stupid case expression stays there.  This actually happened for
-the Integer data type (see Trac #1600 comment:66)!
+the Integer data type (see #1600 comment:66)!
 
 Note [Data con wrappers and GADT syntax]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -821,7 +821,7 @@ strictness/unpackedness to use for the fields of a data type constructor. But
 there is an exception to this rule: newtype constructors. You might not think
 that newtypes would pose a challenge, since newtypes are seemingly forbidden
 from having strictness annotations in the first place. But consider this
-(from Trac #16141):
+(from #16141):
 
   {-# LANGUAGE StrictData #-}
   {-# OPTIONS_GHC -O #-}
@@ -1045,7 +1045,7 @@ And it'd be fine to unpack a product type with existential components
 too, but that would require a bit more plumbing, so currently we don't.
 
 So for now we require: null (dataConExTyCoVars data_con)
-See Trac #14978
+See #14978
 
 Note [Unpack one-wide fields]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1175,7 +1175,7 @@ mkPrimOpId prim_op
                -- We give PrimOps a NOINLINE pragma so that we don't
                -- get silly warnings from Desugar.dsRule (the inline_shadows_rule
                -- test) about a RULE conflicting with a possible inlining
-               -- cf Trac #7287
+               -- cf #7287
 
 -- For each ccall we manufacture a separate CCallOpId, giving it
 -- a fresh unique, a type that is correct for this particular ccall,
@@ -1209,7 +1209,7 @@ mkFCallId dflags uniq fcall ty
     strict_sig = mkClosedStrictSig (replicate arity topDmd) topRes
     -- the call does not claim to be strict in its arguments, since they
     -- may be lifted (foreign import prim) and the called code doesn't
-    -- necessarily force them. See Trac #11076.
+    -- necessarily force them. See #11076.
 {-
 ************************************************************************
 *                                                                      *
@@ -1499,7 +1499,7 @@ are truly used call-by-need, with no code motion.  Key examples:
   Again, it's clear that 'a' will be evaluated strictly (and indeed
   applied to a state token) but we want to make sure that any exceptions
   arising from the evaluation of 'a' are caught by the catch (see
-  Trac #11555).
+  #11555).
 
 Implementing 'lazy' is a bit tricky:
 
@@ -1513,7 +1513,7 @@ Implementing 'lazy' is a bit tricky:
   are exposed in the interface file.  Otherwise, the unfolding for
   (say) pseq in the interface file will not mention 'lazy', so if we
   inline 'pseq' we'll totally miss the very thing that 'lazy' was
-  there for in the first place. See Trac #3259 for a real world
+  there for in the first place. See #3259 for a real world
   example.
 
 * Suppose CorePrep sees (catch# (lazy e) b).  At all costs we must
@@ -1550,7 +1550,7 @@ if library authors could explicitly tell the compiler that a certain lambda is
 called at most once. The oneShot function allows that.
 
 'oneShot' is levity-polymorphic, i.e. the type variables can refer to unlifted
-types as well (Trac #10744); e.g.
+types as well (#10744); e.g.
    oneShot (\x:Int# -> x +# 1#)
 
 Like most magic functions it has a compulsory unfolding, so there is no need

compiler/basicTypes/Module.hs

@@ -199,7 +199,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM
 --        only ever ComponentIds, and some ComponentIds happen to have
 --        more information (UnitIds).
 --      - Same as Language.Haskell.TH.Syntax:PkgName, see
---          https://ghc.haskell.org/trac/ghc/ticket/10279
+--          https://gitlab.haskell.org/ghc/ghc/issues/10279
 --      - The same as PackageKey in GHC 7.10 (we renamed it because
 --        they don't necessarily identify packages anymore.)
 --      - Same as -this-package-key/-package-name flags
@@ -217,7 +217,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM
 -- PackageName: The "name" field in a Cabal file, something like "lens".
 --      - Same as Distribution.Package.PackageName
 --      - DIFFERENT FROM Language.Haskell.TH.Syntax:PkgName, see
---          https://ghc.haskell.org/trac/ghc/ticket/10279
+--          https://gitlab.haskell.org/ghc/ghc/issues/10279
 --      - DIFFERENT FROM -package-name flag
 --      - DIFFERENT FROM the 'name' field in an installed package
 --        information.  This field could more accurately be described

compiler/basicTypes/NameCache.hs

@@ -68,7 +68,7 @@ are two reasons why we might look up an Orig RdrName for built-in syntax,
   * Template Haskell turns a BuiltInSyntax Name into a TH.NameG
     (DsMeta.globalVar), and parses a NameG into an Orig RdrName
     (Convert.thRdrName).  So, e.g. $(do { reify '(,); ... }) will
-    go this route (Trac #8954).
+    go this route (#8954).
 
 -}
 

compiler/basicTypes/OccName.hs

@@ -790,7 +790,7 @@ type TidyOccEnv = UniqFM Int
      - We use trailing digits to subtly indicate a unification variable
        in typechecker error message; see TypeRep.tidyTyVarBndr
 
-We have to take care though! Consider a machine-generated module (Trac #10370)
+We have to take care though! Consider a machine-generated module (#10370)
   module Foo where
      a1 = e1
      a2 = e2

compiler/basicTypes/PatSyn.hs

@@ -118,7 +118,7 @@ In a pattern synonym signature we write
 Note that the "required" context comes first, then the "provided"
 context.  Moreover, the "required" context must not mention
 existentially-bound type variables; that is, ones not mentioned in
-res_ty.  See lots of discussion in Trac #10928.
+res_ty.  See lots of discussion in #10928.
 
 If there is no "provided" context, you can omit it; but you
 can't omit the "required" part (unless you omit both).

compiler/basicTypes/RdrName.hs

@@ -509,7 +509,7 @@ gre_lcl is True, or gre_imp is non-empty.
 
 It is just possible to have *both* if there is a module loop: a Name
 is defined locally in A, and also brought into scope by importing a
-module that SOURCE-imported A.  Exapmle (Trac #7672):
+module that SOURCE-imported A.  Exapmle (#7672):
 
  A.hs-boot   module A where
                data T
@@ -1256,7 +1256,7 @@ Rationale for (a).  Consider
 The unqualified 'x' can only come from import #2.  The qualified 'M.x'
 could come from either, but bestImport picks import #2, because it is
 more likely to be useful in other imports, as indeed it is in this
-case (see Trac #5211 for a concrete example).
+case (see #5211 for a concrete example).
 
 But the rules are not perfect; consider
    import qualified M  -- Import #1

compiler/cmm/CmmSink.hs

@@ -133,7 +133,7 @@ elemLRegSet l = IntSet.member (getKey (getUnique l))
 --
 -- a nice loop, but we didn't eliminate the silly assignment at the end.
 -- See Note [dependent assignments], which would probably fix this.
--- This is #8336 on Trac.
+-- This is #8336.
 --
 -- -----------
 -- (2) From stg_atomically_frame in PrimOps.cmm

compiler/cmm/CmmUtils.hs

@@ -448,7 +448,7 @@ regsOverlap _ reg reg' = reg == reg'
 --
 -- We must check for overlapping registers and not just equal
 -- registers here, otherwise CmmSink may incorrectly reorder
+-- assignments that conflict due to overlap. See #10521 and Note
 -- [Overlapping global registers].
 regUsedIn :: DynFlags -> CmmReg -> CmmExpr -> Bool
 regUsedIn dflags = regUsedIn_ where

compiler/cmm/PprC.hs

@@ -179,7 +179,7 @@ pprAlignment words =
 --
 -- It's a reasonable assumption also known as natural alignment.
 -- Although some architectures have different alignment rules.
--- One of known exceptions is m68k (Trac #11395, comment:16) where:
+-- One of known exceptions is m68k (#11395, comment:16) where:
 --   __alignof__(StgWord) == 2, sizeof(StgWord) == 4
 --
 -- Thus we explicitly increase alignment by using

compiler/codeGen/StgCmmClosure.hs

@@ -732,7 +732,7 @@ blackHoleOnEntry cl_info
 {- Note [Black-holing non-updatable thunks]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 We must not black-hole non-updatable (single-entry) thunks otherwise
-we run into issues like Trac #10414. Specifically:
+we run into issues like #10414. Specifically:
 
   * There is no reason to black-hole a non-updatable thunk: it should
     not be competed for by multiple threads
@@ -745,7 +745,7 @@ we run into issues like Trac #10414. Specifically:
      - is not updated (of course)
      - hence, if it is black-holed and another thread tries to evaluate
        it, that thread will block forever
-    This actually happened in Trac #10414.  So we do not black-hole
+    This actually happened in #10414.  So we do not black-hole
     non-updatable thunks.
 
   * How could two threads evaluate the same non-updatable (single-entry)
@@ -755,7 +755,7 @@ we run into issues like Trac #10414. Specifically:
     thunk, because lazy black-holing only affects thunks with an
     update frame on the stack.
 
-Here is and example due to Reid Barton (Trac #10414):
+Here is and example due to Reid Barton (#10414):
     x = \u []  concat [[1], []]
 with the following definitions,
 

compiler/codeGen/StgCmmExpr.hs

@@ -375,7 +375,7 @@ Suppose we have this STG code:
    f = \[s : State# RealWorld] ->
        case s of _ -> blah
 This is very odd.  Why are we scrutinising a state token?  But it
-can arise with bizarre NOINLINE pragmas (Trac #9964)
+can arise with bizarre NOINLINE pragmas (#9964)
     crash :: IO ()
     crash = IO (\s -> let {-# NOINLINE s' #-}
                           s' = s
@@ -532,7 +532,7 @@ See Note [case on bool]
 
 It's odd, and it's flagrantly inconsistent with the rules described
 Note [Compiling case expressions].  However, after eliminating the
-tagToEnum# (Trac #13397) we will have:
+tagToEnum# (#13397) we will have:
    case (a>b) of ...
 Rather than make it behave quite differently, I am testing for a
 comparison operator here in in the general case as well.

compiler/codeGen/StgCmmHeap.hs

@@ -519,7 +519,7 @@ heapCheck checkStack checkYield do_gc code
                     [" Trying to allocate more than "++show mBLOCK_SIZE++" bytes.",
                      "",
                      "This is currently not possible due to a limitation of GHC's code generator.",
-                     "See http://ghc.haskell.org/trac/ghc/ticket/4505 for details.",
+                     "See https://gitlab.haskell.org/ghc/ghc/issues/4505 for details.",
                      "Suggestion: read data from a file instead of having large static data",
                      "structures in code."]
                  | hpHw > 0  = Just (mkIntExpr dflags (hpHw * (wORD_SIZE dflags)))

compiler/coreSyn/CoreArity.hs

@@ -220,7 +220,7 @@ Now suppose we have:
 Now we want the built-in op/$dfList rule will fire to give
    blah = $copList dCInt
 
-But with eta-expansion 'blah' might (and in Trac #3772, which is
+But with eta-expansion 'blah' might (and in #3772, which is
 slightly more complicated, does) turn into
 
    blah = op (\eta. ($dfList dCInt |> sym co) eta)
@@ -302,7 +302,7 @@ This isn't really right in the presence of seq.  Consider
 This should diverge!  But if we eta-expand, it won't.  We ignore this
 "problem" (unless -fpedantic-bottoms is on), because being scrupulous
 would lose an important transformation for many programs. (See
-Trac #5587 for an example.)
+#5587 for an example.)
 
 Consider also
         f = \x -> error "foo"
@@ -322,7 +322,7 @@ this transformation.  So we try to limit it as much as possible:
 
  (1) Do NOT move a lambda outside a known-bottom case expression
        case undefined of { (a,b) -> \y -> e }
-     This showed up in Trac #5557
+     This showed up in #5557
 
  (2) Do NOT move a lambda outside a case if all the branches of
      the case are known to return bottom.
@@ -334,7 +334,7 @@ this transformation.  So we try to limit it as much as possible:
  (3) Do NOT move a lambda outside a case unless
      (a) The scrutinee is ok-for-speculation, or
      (b) more liberally: the scrutinee is cheap (e.g. a variable), and
-         -fpedantic-bottoms is not enforced (see Trac #2915 for an example)
+         -fpedantic-bottoms is not enforced (see #2915 for an example)
 
 Of course both (1) and (2) are readily defeated by disguising the bottoms.
 
@@ -381,7 +381,7 @@ See also Id.isOneShotBndr.
 Note [State hack and bottoming functions]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 It's a terrible idea to use the state hack on a bottoming function.
-Here's what happens (Trac #2861):
+Here's what happens (#2861):
 
   f :: String -> IO T
   f = \p. error "..."
@@ -410,7 +410,7 @@ Extrude g1.g3
 And now we can repeat the whole loop.  Aargh!  The bug is in applying the
 state hack to a function which then swallows the argument.
 
-This arose in another guise in Trac #3959.  Here we had
+This arose in another guise in #3959.  Here we had
 
      catch# (throw exn >> return ())
 
@@ -590,7 +590,7 @@ says it has arity "infinity" the first time round.
 
 This example happens a lot; it first showed up in Andy Gill's thesis,
 fifteen years ago!  It also shows up in the code for 'rnf' on lists
-in Trac #4138.
+in #4138.
 
 The analysis is easy to achieve because exprEtaExpandArity takes an
 argument
@@ -726,7 +726,7 @@ arityType env (Cast e co)
     -- See Note [exprArity invariant] (2); must be true of
     -- arityType too, since that is how we compute the arity
     -- of variables, and they in turn affect result of exprArity
-    -- Trac #5441 is a nice demo
+    -- #5441 is a nice demo
     -- However, do make sure that ATop -> ATop and ABot -> ABot!
     --   Casts don't affect that part. Getting this wrong provoked #5475