fix some broken links

part of #4476

Author: coke

doc/Language/signatures.rakudoc

@@ -391,7 +391,7 @@ known collectively as I<type smileys>:
     say $f  ~~ Any:U;    # OUTPUT: «False␤»
     say $f  ~~ Any:_;    # OUTPUT: «True␤»
 
-The L<Classes and Objects|/language/classtut#Starting_with_class>
+The L<Classes and Objects|/language/classtut>
 document further elaborates on the concepts of instances and type
 objects and discovering them with the C<.DEFINITE> method.
 
@@ -731,7 +731,7 @@ say zipi( "Hey "); # OUTPUT: «List => (Hey )␤»
 say zipi( 1...* ); # OUTPUT: «Seq => (...)␤»
 
 Slurpy parameters have special behaviors when combined with some
-L<traits and modifiers|#Parameter_Traits_and_Modifiers>,
+L<traits and modifiers|#Parameter_traits_and_modifiers>,
 as described in
 L<the section on slurpy array parameters|/language/signatures#Types_of_slurpy_array_parameters>.
 

doc/Language/structures.rakudoc

@@ -341,7 +341,7 @@ say @fibonacci[14]; # OUTPUT: «987␤»
 =end code
 
 Above we were reifying a L<C<Seq>|/type/Seq> we created with the L<sequence
-operator|/language/operators#index-entry-%E2%80%A6_operators>, but other data
+operator|/language/operators#infix_...>, but other data
 structures use the concept as well. For example, an un-reified
 L<C<Range>|/type/Range> is just the two end points. In some languages, calculating
 the sum of a huge range is a lengthy and memory-consuming process, but Raku

doc/Language/subscripts.rakudoc

@@ -720,8 +720,8 @@ reuse them for any custom type that wants to provide access to data by
 index or key.
 
 You don't have to manually overload the L<C<postcircumfix [ ]>|
-/routine/[ ]#postcircumfix_[_]> and L<C<postcircumfix { }>|
-/routine/{ }#postcircumfix_{_}> operators and re-implement all their magic,
+language/operators#postcircumfix_[_]> and L<C<postcircumfix { }>|
+language/operators#postcircumfix_{_}> operators and re-implement all their magic,
 to achieve that - instead, you can rely on the fact that their standard
 implementation dispatches to a well-defined set of low-level methods behind
 the scenes. For example:

doc/Language/syntax.rakudoc

@@ -566,7 +566,7 @@ String literals are surrounded by quotes:
     say "a string literal\nthat interprets escape sequences";
 
 See L<quoting|/language/quoting> for many more options, including
-L<interpolation quoting C<q>|/language/quoting#Interpolation:_qql>. Raku uses
+L<interpolation quoting C<qq>|/language/quoting#Interpolation:_qq>. Raku uses
 the standard escape characters in literals: C<\0 \a \b \t \n \f \r \e>,
 with the same meaning as the ASCII escape codes, specified in
 L<the design document|https://design.raku.org/S02.html#Backslash_sequences>.

doc/Language/traps.rakudoc

@@ -492,7 +492,7 @@ say 12_345.contains("2_");  # OUTPUT: «False␤»
 
 A common task is to retrieve one or more random elements from a collection,
 but C<List.rand> isn't the way to do that. L<C<Cool>|/type/Cool> provides
-L<rand|/type/Cool#routine_rand>, but that first coerces the L<C<List>|/type/List> into
+L<rand|/type/Cool#method_rand>, but that first coerces the L<C<List>|/type/List> into
 the number of items in the list, and returns a random real number
 between 0 and that value. To get random elements, see L<pick|/routine/pick>
 and L<roll|/routine/roll>.
@@ -1295,7 +1295,7 @@ say doesn't-return-ret;
 # BAD: outputs «Nil» and a warning «Useless use of constant string "ret" in sink context (line 13)»
 =end code
 
-Code for C<returns-ret> and C<doesn't-return-ret> might look exactly the same, since in principle it does not matter where the L<C<CATCH>|/language/phasers#index-entry-Phasers__CATCH-CATCH> block goes. However, a block is an object and the last object in a C<sub> will be returned, so the C<doesn't-return-ret> will return L<C<Nil>|/type/Nil>, and, besides, since "ret" will be now in sink context, it will issue a warning. In case you want to place phasers last for conventional reasons, use the explicit form of C<return>.
+Code for C<returns-ret> and C<doesn't-return-ret> might look exactly the same, since in principle it does not matter where the L<C<CATCH>|/language/phasers#CATCH> block goes. However, a block is an object and the last object in a C<sub> will be returned, so the C<doesn't-return-ret> will return L<C<Nil>|/type/Nil>, and, besides, since "ret" will be now in sink context, it will issue a warning. In case you want to place phasers last for conventional reasons, use the explicit form of C<return>.
 
 =begin code
 sub explicitly-return-ret () {
@@ -1309,7 +1309,7 @@ sub explicitly-return-ret () {
 =head2 C<LEAVE> needs explicit return from a sub to run
 
 As the documentation for the
-L<C<LEAVE> phaser indicates|/language/phasers#index-entry-Phasers__LEAVE-LEAVE>
+L<C<LEAVE> phaser indicates|/language/phasers#LEAVE>
 C<LEAVE> runs when a block is exited, "... except when the program exits
 abruptly". That is, unlike C<END>, it's going to be invoked only if the block
 actually returns in an orderly way. This is why:
@@ -1482,7 +1482,7 @@ Died with the exception:
 
 Resolving this is easy because C<.print> returns a promise that you
 can await on. The solution is even more beautiful if you are
-working in a L<react|/language/concurrency#index-entry-react> block:
+working in a L<react|/language/concurrency#react> block:
 
 =begin code :skip-test<$proc needs a complex initialization>
 whenever $proc.print: “one\ntwo\nthree\nfour” {
@@ -1984,7 +1984,7 @@ kind of action in the map code block:
     <þor oðin loki>.map: *.codes.say; # OUTPUT: «3␤4␤4␤»
 
 The problem might arise when maps are nested and L<in a sink
-context|/language/contexts#index-entry-sink_context>.
+context|/language/contexts#Sink>.
 
     <foo bar ber>.map: { $^a.comb.map: { $^b.say}}; # OUTPUT: «»
 
@@ -2035,7 +2035,7 @@ say @a.grep( *.Int ~~ 2 );
 The error message does not make a lot of sense. It does, however, if you
 put it in terms of the C<ACCEPTS> method: that code is equivalent to
 C<2.ACCEPTS( *.Int )>, but C<*.Int> cannot be
-L<coerced to L<C<Numeric>|/type/Numeric>|/routine/ACCEPTS#(Numeric)_method_ACCEPTS>,
+L<coerced to L<C<Numeric>|/type/Numeric>|/type/Numeric#method_ACCEPTS>,
 being as it is a L<C<Block>|/type/Block>.
 
 Solution: don't use L<C<WhateverCode>|/type/WhateverCode> in the left hand side of a