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#)