Fix many broken links

Note that contrary to what docgen.rst currently says, the ids have
to match exactly or else most web browsers will not jump to the
intended symbol.

1 files changed, 11 insertions, 11 deletions

diff --git a/doc/backends.rst b/doc/backends.rst
index f6321942c..b003a274c 100644
--- a/doc/backends.rst
+++ b/doc/backends.rst
@@ -107,7 +107,7 @@ Nim code calling the backend
 
 Nim code can interface with the backend through the `Foreign function
 interface <manual.html#foreign-function-interface>`_ mainly through the
-`importc pragma <manual.html#importc-pragma>`_. The ``importc`` pragma is the
+`importc pragma <manual.html#foreign-function-interface-importc-pragma>`_. The ``importc`` pragma is the
 *generic* way of making backend symbols available in Nim and is available
 in all the target backends (JavaScript too).  The C++ or Objective-C backends
 have their respective `ImportCpp <manual.html#implementation-specific-pragmas-importcpp-pragma>`_ and
@@ -124,16 +124,16 @@ statically or dynamically. The preferred way of integrating native code is to
 use dynamic linking because it allows you to compile Nim programs without
 the need for having the related development libraries installed. This is done
 through the `dynlib pragma for import
-<manual.html#dynlib-pragma-for-import>`_, though more specific control can be
+<manual.html#foreign-function-interface-dynlib-pragma-for-import>`_, though more specific control can be
 gained using the `dynlib module <dynlib.html>`_.
 
 The `dynlibOverride <nimc.html#dynliboverride>`_ command line switch allows
 to avoid dynamic linking if you need to statically link something instead.
 Nim wrappers designed to statically link source files can use the `compile
-pragma <nimc.html#compile-pragma>`_ if there are few sources or providing
+pragma <manual.html#implementation-specific-pragmas-compile-pragma>`_ if there are few sources or providing
 them along the Nim code is easier than using a system library. Libraries
 installed on the host system can be linked in with the `PassL pragma
-<nimc.html#passl-pragma>`_.
+<manual.html#implementation-specific-pragmas-passl-pragma>`_.
 
 To wrap native code, take a look at the `c2nim tool <https://nim-lang.org/docs/c2nim.html>`_ which helps
 with the process of scanning and transforming header files into a Nim
@@ -215,7 +215,7 @@ Backend code calling Nim
 ------------------------
 
 Backend code can interface with Nim code exposed through the `exportc
-pragma <manual.html#exportc-pragma>`_. The ``exportc`` pragma is the *generic*
+pragma <manual.html#foreign-function-interface-exportc-pragma>`_. The ``exportc`` pragma is the *generic*
 way of making Nim symbols available to the backends. By default the Nim
 compiler will mangle all the Nim symbols to avoid any name collision, so
 the most significant thing the ``exportc`` pragma does is maintain the Nim
@@ -329,7 +329,7 @@ Nimcache naming logic
 The `nimcache`:idx: directory is generated during compilation and will hold
 either temporary or final files depending on your backend target. The default
 name for the directory depends on the used backend and on your OS but you can
-use the ``--nimcache`` `compiler switch <nimc.html#command-line-switches>`_ to
+use the ``--nimcache`` `compiler switch <nimc.html#compiler-usage-command-line-switches>`_ to
 change it.
 
 
@@ -349,14 +349,14 @@ Strings and C strings
 ---------------------
 
 The manual mentions that `Nim strings are implicitly convertible to
-cstrings <manual.html#cstring-type>`_ which makes interaction usually
+cstrings <manual.html#types-cstring-type>`_ which makes interaction usually
 painless. Most C functions accepting a Nim string converted to a
 ``cstring`` will likely not need to keep this string around and by the time
 they return the string won't be needed any more. However, for the rare cases
 where a Nim string has to be preserved and made available to the C backend
 as a ``cstring``, you will need to manually prevent the string data from being
-freed with `GC_ref <system.html#GC_ref>`_ and `GC_unref
-<system.html#GC_unref>`_.
+freed with `GC_ref <system.html#GC_ref,string>`_ and `GC_unref
+<system.html#GC_unref,string>`_.
 
 A similar thing happens with C code invoking Nim code which returns a
 ``cstring``. Consider the following proc:
@@ -382,9 +382,9 @@ Custom data types
 Just like strings, custom data types that are to be shared between Nim and
 the backend will need careful consideration of who controls who. If you want
 to hand a Nim reference to C code, you will need to use `GC_ref
-<system.html#GC_ref>`_ to mark the reference as used, so it does not get
+<system.html#GC_ref,ref.T>`_ to mark the reference as used, so it does not get
 freed. And for the C backend you will need to expose the `GC_unref
-<system.html#GC_unref>`_ proc to clean up this memory when it is not required
+<system.html#GC_unref,ref.T>`_ proc to clean up this memory when it is not required
 any more.
 
 Again, if you are wrapping a library which *mallocs* and *frees* data