Update Trac ticket URLs to point to GitLab

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

3 files changed, 31 insertions, 31 deletions

diff --git a/compiler/specialise/Rules.hs b/compiler/specialise/Rules.hs
index ad6a0757cb..df6196a655 100644
--- a/compiler/specialise/Rules.hs
+++ b/compiler/specialise/Rules.hs
@@ -440,7 +440,7 @@ isMoreSpecific :: CoreRule -> CoreRule -> Bool
 -- anything else, because we want user-define rules to "win"
 -- In particular, class ops have a built-in rule, but we
 -- any user-specific rules to win
---   eg (Trac #4397)
+--   eg (#4397)
 --      truncate :: (RealFrac a, Integral b) => a -> b
 --      {-# RULES "truncate/Double->Int" truncate = double2Int #-}
 --      double2Int :: Double -> Int
@@ -619,7 +619,7 @@ It can be the case that the binder in a rule is not actually
 bound on the LHS:
 
 * Type variables.  Type synonyms with phantom args can give rise to
-  unbound template type variables.  Consider this (Trac #10689,
+  unbound template type variables.  Consider this (#10689,
   simplCore/should_compile/T10689):
 
     type Foo a b = b
@@ -653,7 +653,7 @@ bound on the LHS:
   fires we can substitute <t> for c.
 
   This actually happened (in a RULE for a local function)
-  in Trac #13410, and also in test T10602.
+  in #13410, and also in test T10602.
 
 
 Note [Cloning the template binders]
@@ -674,11 +674,11 @@ binders if they are already in scope.
 ------ Historical note -------
 At one point I tried simply adding the template binders to the
 in-scope set /without/ cloning them, but that failed in a horribly
-obscure way in Trac #14777.  Problem was that during matching we look
+obscure way in #14777.  Problem was that during matching we look
 up target-term variables in the in-scope set (see Note [Lookup
 in-scope]).  If a target-term variable happens to name-clash with a
 template variable, that lookup will find the template variable, which
-is /utterly/ bogus.  In Trac #14777, this transformed a term variable
+is /utterly/ bogus.  In #14777, this transformed a term variable
 into a type variable, and then crashed when we wanted its idInfo.
 ------ End of historical note -------
 
diff --git a/compiler/specialise/SpecConstr.hs b/compiler/specialise/SpecConstr.hs
index b07e480ff5..8ced5a87c0 100644
--- a/compiler/specialise/SpecConstr.hs
+++ b/compiler/specialise/SpecConstr.hs
@@ -506,13 +506,13 @@ sc_force to True when calling specLoop. This flag does four things:
   * Ignore specConstrCount, to make arbitrary numbers of specialisations
         (see specialise)
   * Specialise even for arguments that are not scrutinised in the loop
-        (see argToPat; Trac #4448)
+        (see argToPat; #4448)
   * Only specialise on recursive types a finite number of times
-        (see is_too_recursive; Trac #5550; Note [Limit recursive specialisation])
+        (see is_too_recursive; #5550; Note [Limit recursive specialisation])
 
 The flag holds only for specialising a single binding group, and NOT
 for nested bindings.  (So really it should be passed around explicitly
-and not stored in ScEnv.)  Trac #14379 turned out to be caused by
+and not stored in ScEnv.)  #14379 turned out to be caused by
    f SPEC x = let g1 x = ...
               in ...
 We force-specialise f (because of the SPEC), but that generates a specialised
@@ -599,7 +599,7 @@ more than N times (controlled by -fspec-constr-recursive=N) we check
     specialisations.  If sc_count is "no limit" then we arbitrarily
     choose 10 as the limit (ugh).
 
-See Trac #5550.   Also Trac #13623, where this test had become over-aggressive,
+See #5550.   Also #13623, where this test had become over-aggressive,
 and we lost a wonderful specialisation that we really wanted!
 
 Note [NoSpecConstr]
@@ -746,7 +746,7 @@ because the x-binding still exists and we've now duplicated (expensive v).
 
 This seldom happens because let-bound constructor applications are
 ANF-ised, but it can happen as a result of on-the-fly transformations in
-SpecConstr itself.  Here is Trac #7865:
+SpecConstr itself.  Here is #7865:
 
         let {
           a'_shr =
@@ -946,7 +946,7 @@ extendBndr  env bndr  = (env { sc_subst = subst' }, bndr')
 extendValEnv :: ScEnv -> Id -> Maybe Value -> ScEnv
 extendValEnv env _  Nothing   = env
 extendValEnv env id (Just cv)
- | valueIsWorkFree cv      -- Don't duplicate work!!  Trac #7865
+ | valueIsWorkFree cv      -- Don't duplicate work!!  #7865
  = env { sc_vals = extendVarEnv (sc_vals env) id cv }
 extendValEnv env _ _ = env
 
@@ -1048,7 +1048,7 @@ So in extendCaseBndrs we must *also* add the binding
 else we lose a useful specialisation for f.  This is necessary even
 though the simplifier has systematically replaced uses of 'x' with 'y'
 and 'b' with 'c' in the code.  The use of 'b' in the ValueEnv came
-from outside the case.  See Trac #4908 for the live example.
+from outside the case.  See #4908 for the live example.
 
 Note [Avoiding exponential blowup]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1786,7 +1786,7 @@ the passed-in SpecInfo, unless there are no calls at all to the function.
 The caller can, indeed must, assume this.  He should not combine in rhs_usg
 himself, or he'll get rhs_usg twice -- and that can lead to an exponential
 blowup of duplicates in the CallEnv.  This is what gave rise to the massive
-performance loss in Trac #8852.
+performance loss in #8852.
 
 Note [Specialise original body]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1827,7 +1827,7 @@ Now we want f_spec to have strictness  LLS, otherwise we'll use call-by-need
 when calling f_spec instead of call-by-value.  And that can result in
 unbounded worsening in space (cf the classic foldl vs foldl')
 
-See Trac #3437 for a good example.
+See #3437 for a good example.
 
 The function calcSpecStrictness performs the calculation.
 
@@ -1862,7 +1862,7 @@ via 'a' itself, or be in scope at f's defn.  Hence we just take
 BUT phantom type synonyms can mess this reasoning up,
   eg   x::T b   with  type T b = Int
 So we apply expandTypeSynonyms to the bound Ids.
-See Trac # 5458.  Yuk.
+See # 5458.  Yuk.
 
 Note [SpecConstr call patterns]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1875,7 +1875,7 @@ because both of these will be optimised by Simplify.simplRule. In the
 former case such optimisation benign, because the rule will match more
 terms; but in the latter we may lose a binding of 'g1' or 'g2', and
 end up with a rule LHS that doesn't bind the template variables
-(Trac #10602).
+(#10602).
 
 The simplifier eliminates such things, but SpecConstr itself constructs
 new terms by substituting.  So the 'mkCast' in the Cast case of scExpr
@@ -1902,7 +1902,7 @@ by trim_pats.
 
 Note [SpecConstr and casts]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Consider (Trac #14270) a call like
+Consider (#14270) a call like
 
     let f = e
     in ... f (K @(a |> co)) ...
@@ -1925,7 +1925,7 @@ call patterns that
 
 I think this is very rare.
 
-It is important (e.g. Trac #14936) that this /only/ applies to
+It is important (e.g. #14936) that this /only/ applies to
 coercions mentioned in casts.  We don't want to be discombobulated
 by casts in terms!  For example, consider
    f ((e1,e2) |> sym co)
@@ -2049,7 +2049,7 @@ trim_pats env fn (SI { si_n_specs = done_spec_count }) pats
 
     emit_trace result
        | debugIsOn || hasPprDebug (sc_dflags env)
-         -- Suppress this scary message for ordinary users!  Trac #5125
+         -- Suppress this scary message for ordinary users!  #5125
        = pprTrace "SpecConstr" msg result
        | otherwise
        = result
diff --git a/compiler/specialise/Specialise.hs b/compiler/specialise/Specialise.hs
index f391781c43..c62789017f 100644
--- a/compiler/specialise/Specialise.hs
+++ b/compiler/specialise/Specialise.hs
@@ -628,7 +628,7 @@ which explodes in size when aggressively optimized. The
 -fno-cross-module-specialise option was introduced to allow users to being
 bitten by such instances to revert to the pre-7.10 behavior.
 
-See Trac #10491
+See #10491
 -}
 
 -- | Specialise a set of calls to imported bindings
@@ -793,7 +793,7 @@ What imported functions do we specialise?  The basic set is
 but with -fspecialise-aggressively we add
  * Anything with an unfolding template
 
-Trac #8874 has a good example of why we want to auto-specialise DFuns.
+#8874 has a good example of why we want to auto-specialise DFuns.
 
 We have the -fspecialise-aggressively flag (usually off), because we
 risk lots of orphan modules from over-vigorous specialisation.
@@ -1384,7 +1384,7 @@ defeated specialisation!  Hence the use of collectBindersPushingCo.
 
 Note [Evidence foralls]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
-Suppose (Trac #12212) that we are specialising
+Suppose (#12212) that we are specialising
    f :: forall a b. (Num a, F a ~ F b) => blah
 with a=b=Int. Then the RULE will be something like
    RULE forall (d:Num Int) (g :: F Int ~ F Int).
@@ -1506,7 +1506,7 @@ In general, we need only make this Rec if
 Note [Avoiding loops]
 ~~~~~~~~~~~~~~~~~~~~~
 When specialising /dictionary functions/ we must be very careful to
-avoid building loops. Here is an example that bit us badly: Trac #3591
+avoid building loops. Here is an example that bit us badly: #3591
 
      class Eq a => C a
      instance Eq [a] => C [a]
@@ -1547,7 +1547,7 @@ Solution:
 
 --------------
 Here's another example, this time for an imported dfun, so the call
-to filterCalls is in specImports (Trac #13429). Suppose we have
+to filterCalls is in specImports (#13429). Suppose we have
   class Monoid v => C v a where ...
 
 We start with a call
@@ -1785,7 +1785,7 @@ all they should be inlined, right?  Two reasons:
    This particular example had a huge effect on the call to replicateM_
    in nofib/shootout/n-body.
 
-Why (b): discard INLINABLE pragmas? See Trac #4874 for persuasive examples.
+Why (b): discard INLINABLE pragmas? See #4874 for persuasive examples.
 Suppose we have
     {-# INLINABLE f #-}
     f :: Ord a => [a] -> Int
@@ -1803,7 +1803,7 @@ So we simply drop INLINABLE pragmas when specialising. It's not really
 a complete solution; ignoring specialisation for now, INLINABLE functions
 don't get properly strictness analysed, for example. But it works well
 for examples involving specialisation, which is the dominant use of
-INLINABLE.  See Trac #4874.
+INLINABLE.  See #4874.
 
 
 ************************************************************************
@@ -2009,7 +2009,7 @@ mkCallUDs' env f args
             ClassPred cls _ -> not (isIPClass cls)  -- Superclasses can't be IPs
             EqPred {}       -> True
             IrredPred {}    -> True   -- Things like (D []) where D is a
-                                      -- Constraint-ranged family; Trac #7785
+                                      -- Constraint-ranged family; #7785
             ForAllPred {}   -> True
 
 {-
@@ -2018,7 +2018,7 @@ Note [Type determines value]
 Only specialise if all overloading is on non-IP *class* params,
 because these are the ones whose *type* determines their *value*.  In
 parrticular, with implicit params, the type args *don't* say what the
-value of the implicit param is!  See Trac #7101
+value of the implicit param is!  See #7101
 
 However, consider
          type family D (v::*->*) :: Constraint
@@ -2032,7 +2032,7 @@ So the question is: can an implicit parameter "hide inside" a
 type-family constraint like (D a).  Well, no.  We don't allow
         type instance D Maybe = ?x:Int
 Hence the IrredPred case in type_determines_value.
-See Trac #7785.
+See #7785.
 
 Note [Interesting dictionary arguments]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2058,7 +2058,7 @@ variables?
 
 We accidentally lost accurate tracking of local variables for a long
 time, because cloned variables don't have unfoldings. But makes a
-massive difference in a few cases, eg Trac #5113. For nofib as a
+massive difference in a few cases, eg #5113. For nofib as a
 whole it's only a small win: 2.2% improvement in allocation for ansi,
 1.2% for bspt, but mostly 0.0!  Average 0.1% increase in binary size.
 -}
@@ -2117,7 +2117,7 @@ pair_fvs (bndr, rhs) = exprSomeFreeVars interesting rhs
         --         involving an imported dfun.  We must know whether
         --         a dictionary binding depends on an imported dfun,
         --         in case we try to specialise that imported dfun
-        --         Trac #13429 illustrates
+        --         #13429 illustrates
 
 -- | Flatten a set of "dumped" 'DictBind's, and some other binding
 -- pairs, into a single recursive binding.