docs: Correct wording in LangRef relating to available_externally linkage.

[mehdi_amini]

Looks good to me, let's wait for Rafael.

[• rafael]

docs/LangRef.rst

214

Maybe drop the reference to linkonce_odr completely?

[pcc]

• Remove reference to linkonce_odr linkage

[• rafael]

LGTM

docs/LangRef.rst

``private``
     private to be renamed as necessary to avoid collisions. Because the
     symbol is private to the module, all references can be updated. This
     doesn't show up in any symbol table in the object file.
 ``internal``
     Similar to private, but the value shows as a local symbol
     (``STB_LOCAL`` in the case of ELF) in the object file. This
     corresponds to the notion of the '``static``' keyword in C.
 ``available_externally``
-    Globals with "``available_externally``" linkage are never emitted
-    into the object file corresponding to the LLVM module. They exist to
-    allow inlining and other optimizations to take place given knowledge
-    of the definition of the global, which is known to be somewhere
-    outside the module. Globals with ``available_externally`` linkage
-    are allowed to be discarded at will, and are otherwise the same as
-    ``linkonce_odr``. This linkage type is only allowed on definitions,
-    not declarations.
+    Globals with "``available_externally``" linkage are never emitted into
+    the object file corresponding to the LLVM module. From the linker's
+    perspective, an ``available_externally`` global is equivalent to
+    an external declaration. They exist to allow inlining and other
+    optimizations to take place given knowledge of the definition of the
+    global, which is known to be somewhere outside the module. Globals
+    with ``available_externally`` linkage are allowed to be discarded at
+    will, and allow inlining and other optimizations. This linkage type is
+    only allowed on definitions, not declarations.
 ``linkonce``
     Globals with "``linkonce``" linkage are merged with other globals of
     the same name when linkage occurs. This can be used to implement
     some forms of inline functions, templates, or other code which must
     be generated in each translation unit that uses it, but where the
     body may be overridden with a more definitive definition later.
     Unreferenced ``linkonce`` globals are allowed to be discarded. Note
     that ``linkonce`` linkage does not actually allow the optimizer to