Add and simplify links to erlang documentation (#14179)

sabiwara · web-flow · commit 08d844a20643 · 2025-01-12T18:58:38.000+09:00
* Link more erlang modules in docs

* Fix epmd link

* Use `:atom` syntax to link erlang modules
diff --git a/lib/elixir/lib/json.ex b/lib/elixir/lib/json.ex
@@ -356,7 +356,7 @@ defmodule JSON do
     * for `string`: `&Function.identity/1`
     * for `null`: the atom `nil`
 
-  For streaming decoding, see Erlang's `:json` module.
+  For streaming decoding, see Erlang's [`:json`](`:json`) module.
   """
   @spec decode(binary(), term(), keyword()) ::
           {term(), term(), binary()} | {:error, decode_error_reason()}
diff --git a/lib/elixir/lib/kernel.ex b/lib/elixir/lib/kernel.ex
@@ -60,7 +60,7 @@ defmodule Kernel do
 
     * Bitstring - a sequence of bits, created with `<<>>/1`.
       When the number of bits is divisible by 8, they are called binaries and can
-      be manipulated with Erlang's `:binary` module
+      be manipulated with Erlang's [`:binary`](`:binary`) module
     * Reference - a unique value in the runtime system, created with `make_ref/0`
 
   ### Data types
@@ -5722,7 +5722,7 @@ defmodule Kernel do
   >
   >   * If using `defoverridable`, avoid relying on `super` to trigger the default
   >     behaviour, suggesting users to invoke well-defined APIs instead.
-  > 
+  >
   """
   defmacro defoverridable(keywords_or_behaviour) do
     quote do
diff --git a/lib/elixir/lib/map_set.ex b/lib/elixir/lib/map_set.ex
@@ -43,8 +43,7 @@ defmodule MapSet do
   `MapSet`s can also be constructed starting from other collection-type data
   structures: for example, see `MapSet.new/1` or `Enum.into/2`.
 
-  `MapSet` is built on top of Erlang's
-  [`:sets`](https://www.erlang.org/doc/man/sets.html) (version 2). This means
+  `MapSet` is built on top of Erlang's [`:sets`](`:sets`) (version 2). This means
   that they share many properties, including logarithmic time complexity. Erlang
   `:sets` (version 2) are implemented on top of maps, so see the documentation
   for `Map` for more information on its execution time complexity.
diff --git a/lib/elixir/lib/string.ex b/lib/elixir/lib/string.ex
@@ -172,7 +172,7 @@ defmodule String do
   Standard Annex #29](https://www.unicode.org/reports/tr29/).
 
   For converting a binary to a different encoding and for Unicode
-  normalization mechanisms, see Erlang's `:unicode` module.
+  normalization mechanisms, see Erlang's [`:unicode`](`:unicode`) module.
 
   ## String and binary operations
 
diff --git a/lib/elixir/pages/anti-patterns/process-anti-patterns.md b/lib/elixir/pages/anti-patterns/process-anti-patterns.md
@@ -227,7 +227,7 @@ This anti-pattern has many potential remedies:
 
   * If the only process that needs data is the one you are sending to, consider making the process fetch that data instead of passing it.
 
-  * Some abstractions, such as [`:persistent_term`](https://www.erlang.org/doc/man/persistent_term.html), allows you to share data between processes, as long as such data changes infrequently.
+  * Some abstractions, such as [`:persistent_term`](`:persistent_term`), allows you to share data between processes, as long as such data changes infrequently.
 
 In our case, limiting the input data is a reasonable strategy. If all we need *right now* is the IP address, then let's only work with that and make sure we're only passing the IP address into the closure, like so:
 
diff --git a/lib/elixir/pages/getting-started/debugging.md b/lib/elixir/pages/getting-started/debugging.md
@@ -175,11 +175,11 @@ Finally, remember you can also get a mini-overview of the runtime info by callin
 
 We have just scratched the surface of what the Erlang VM has to offer, for example:
 
-  * Alongside the observer application, Erlang also includes a [`:crashdump_viewer`](https://www.erlang.org/doc/man/crashdump_viewer.html) to view crash dumps
+  * Alongside the observer application, Erlang also includes a [`:crashdump_viewer`](`:crashdump_viewer`) to view crash dumps
 
   * Integration with OS level tracers, such as [Linux Trace Toolkit,](https://www.erlang.org/doc/apps/runtime_tools/lttng) [DTRACE,](https://www.erlang.org/doc/apps/runtime_tools/dtrace) and [SystemTap](https://www.erlang.org/doc/apps/runtime_tools/systemtap)
 
-  * [Microstate accounting](http://www.erlang.org/doc/man/msacc.html) measures how much time the runtime spends in several low-level tasks in a short time interval
+  * [Microstate accounting](`:msacc`) measures how much time the runtime spends in several low-level tasks in a short time interval
 
   * Mix ships with many tasks under the `profile` namespace, such as `mix profile.cprof` and `mix profile.fprof`
 
diff --git a/lib/elixir/pages/mix-and-otp/agents.md b/lib/elixir/pages/mix-and-otp/agents.md
@@ -9,7 +9,7 @@ If you have skipped the *Getting Started* guide or read it long ago, be sure to
 Elixir is an immutable language where nothing is shared by default. If we want to share information, which can be read and modified from multiple places, we have two main options in Elixir:
 
   * Using processes and message passing
-  * [ETS (Erlang Term Storage)](http://www.erlang.org/doc/man/ets.html)
+  * [ETS (Erlang Term Storage)](`:ets`)
 
 We covered processes in the *Getting Started* guide. ETS (Erlang Term Storage) is a new topic that we will explore in later chapters. When it comes to processes though, we rarely hand-roll our own, instead we use the abstractions available in Elixir and OTP:
 
diff --git a/lib/elixir/pages/mix-and-otp/distributed-tasks.md b/lib/elixir/pages/mix-and-otp/distributed-tasks.md
@@ -15,7 +15,7 @@ The router will check the first byte of the bucket name against the table and di
 
 If the matching entry points to the node evaluating the request, then we've finished routing, and this node will perform the requested operation. If the matching entry points to a different node, we'll pass the request to said node, which will look at its own routing table (which may be different from the one in the first node) and act accordingly. If no entry matches, an error will be raised.
 
-> Note: we will be using two nodes in the same machine throughout this chapter. You are free to use two (or more) different machines on the same network but you need to do some prep work. First of all, you need to ensure all machines have a `~/.erlang.cookie` file with exactly the same value. Then you need to guarantee [epmd](http://www.erlang.org/doc/man/epmd.html) is running on a port that is not blocked (you can run `epmd -d` for debug info).
+> Note: we will be using two nodes in the same machine throughout this chapter. You are free to use two (or more) different machines on the same network but you need to do some prep work. First of all, you need to ensure all machines have a `~/.erlang.cookie` file with exactly the same value. Then you need to guarantee [epmd](https://www.erlang.org/doc/apps/erts/epmd_cmd) is running on a port that is not blocked (you can run `epmd -d` for debug info).
 
 ## Our first distributed code
 
@@ -86,7 +86,7 @@ From our quick exploration, we could conclude that we should use `Node.spawn_lin
 
 There are three better alternatives to `Node.spawn_link/2` that we could use in our implementation:
 
-1. We could use Erlang's [:erpc](http://www.erlang.org/doc/man/erpc.html) module to execute functions on a remote node. Inside the `bar@computer-name` shell above, you can call `:erpc.call(:"foo@computer-name", Hello, :world, [])` and it will print "hello world"
+1. We could use Erlang's [`:erpc`](`:erpc`) module to execute functions on a remote node. Inside the `bar@computer-name` shell above, you can call `:erpc.call(:"foo@computer-name", Hello, :world, [])` and it will print "hello world"
 
 2. We could have a server running on the other node and send requests to that node via the `GenServer` API. For example, you can call a server on a remote node by using `GenServer.call({name, node}, arg)` or passing the remote process PID as the first argument
 
@@ -347,8 +347,8 @@ Distributed key-value stores, used in real-life, need to consider the fact nodes
 These topics can be daunting at first but remember that most Elixir frameworks abstract those concerns for you. For example, when using [the Phoenix web framework](https://phoenixframework.org), its plug-and-play abstractions take care of sending messages and tracking how users join and leave a cluster. However, if you are interested in distributed systems after all, there is much to explore. Here are some additional references:
 
   * [The excellent Distribunomicon chapter from Learn You Some Erlang](http://learnyousomeerlang.com/distribunomicon)
-  * [Erlang's global module](https://www.erlang.org/doc/man/global.html), which can provide global names and global locks, allowing unique names and unique locks in a whole cluster of machines
-  * [Erlang's pg module](https://www.erlang.org/doc/man/pg.html), which allows process to join different groups shared across the whole cluster
+  * Erlang's [`:global` module](`:global`), which can provide global names and global locks, allowing unique names and unique locks in a whole cluster of machines
+  * Erlang's [`:pg` module](`:pg`), which allows process to join different groups shared across the whole cluster
   * [Phoenix PubSub project](https://github.com/phoenixframework/phoenix_pubsub), which provides a distributed messaging system and a distributed presence system for tracking users and processes in a cluster
 
 You will also find many libraries for building distributed systems within the overall Erlang ecosystem. For now, it is time to go back to our simple distributed key-value store and learn how to configure and package it for production.
diff --git a/lib/elixir/pages/mix-and-otp/erlang-term-storage.md b/lib/elixir/pages/mix-and-otp/erlang-term-storage.md
@@ -8,7 +8,7 @@ In this chapter, we will learn about ETS (Erlang Term Storage) and how to use it
 
 ## ETS as a cache
 
-ETS allows us to store any Elixir term in an in-memory table. Working with ETS tables is done via [Erlang's `:ets` module](http://www.erlang.org/doc/man/ets.html):
+ETS allows us to store any Elixir term in an in-memory table. Working with ETS tables is done via [Erlang's `:ets` module](`:ets`):
 
 ```elixir
 iex> table = :ets.new(:buckets_registry, [:set, :protected])
diff --git a/lib/elixir/pages/mix-and-otp/task-and-gen-tcp.md b/lib/elixir/pages/mix-and-otp/task-and-gen-tcp.md
@@ -1,6 +1,6 @@
 # Task and gen_tcp
 
-In this chapter, we are going to learn how to use [Erlang's `:gen_tcp` module](http://www.erlang.org/doc/man/gen_tcp.html) to serve requests. This provides a great opportunity to explore Elixir's `Task` module. In future chapters, we will expand our server so that it can actually serve the commands.
+In this chapter, we are going to learn how to use Erlang's [`:gen_tcp` module](`:gen_tcp`) to serve requests. This provides a great opportunity to explore Elixir's `Task` module. In future chapters, we will expand our server so that it can actually serve the commands.
 
 ## Echo server
 
diff --git a/lib/ex_unit/lib/ex_unit.ex b/lib/ex_unit/lib/ex_unit.ex
@@ -14,7 +14,7 @@ defmodule ExUnit do
       # 2) Create a new test module and use "ExUnit.Case".
       defmodule AssertionTest do
         # 3) Note that we pass "async: true", this runs the tests in the
-        #    test module concurrently with other test modules. The 
+        #    test module concurrently with other test modules. The
         #    individual tests within each test module are still run serially.
         use ExUnit.Case, async: true
 
@@ -311,7 +311,7 @@ defmodule ExUnit do
 
     * `:rand_algorithm` - algorithm to be used when generating the test seed.
       Available algorithms can be found in Erlang's
-      [`:rand`](https://www.erlang.org/doc/man/rand.html) documentation (see
+      [`:rand`](`:rand`) documentation (see
       [`:rand.builting_arg/0`](https://www.erlang.org/doc/apps/stdlib/rand.html#t:builtin_alg/0)).
       Available since v1.16.0. Before v1.16.0, the algorithm was hard-coded to
       `:exs1024`. On Elixir v1.16.0 and after, the default changed to `:exsss`;
@@ -321,8 +321,8 @@ defmodule ExUnit do
 
     * `:seed` - an integer seed value to randomize the test suite. This seed
       is also mixed with the test module and name to create a new unique seed
-      on every test, which is automatically fed into the `:rand` module. This
-      provides randomness between tests, but predictable and reproducible
+      on every test, which is automatically fed into the [`:rand`](`:rand`) module.
+      This provides randomness between tests, but predictable and reproducible
       results. A `:seed` of `0` will disable randomization and the tests in each
       file will always run in the order that they were defined in;
 
diff --git a/lib/mix/lib/mix/tasks/profile.eprof.ex b/lib/mix/lib/mix/tasks/profile.eprof.ex
@@ -82,7 +82,7 @@ defmodule Mix.Tasks.Profile.Eprof do
   ## Caveats
 
   You should be aware that the code being profiled is running in an anonymous
-  function which is invoked by [`:eprof` module](https://www.erlang.org/doc/man/eprof.html).
+  function which is invoked by [`:eprof` module](`:eprof`).
   Thus, you'll see some additional entries in your profile output. It is also
   important to note that the profiler is stopped as soon as the code has finished running,
   and this may need special attention, when: running asynchronous code as function calls which were
diff --git a/lib/mix/lib/mix/tasks/profile.fprof.ex b/lib/mix/lib/mix/tasks/profile.fprof.ex
@@ -93,7 +93,7 @@ defmodule Mix.Tasks.Profile.Fprof do
   ## Caveats
 
   You should be aware that the code being profiled is running in an anonymous
-  function which is invoked by [`:fprof` module](https://www.erlang.org/doc/man/fprof.html).
+  function which is invoked by [`:fprof` module](`:fprof`).
   Thus, you'll see some additional entries in your profile output,
   such as `:fprof` calls, an anonymous
   function with high ACC time, or an `:undefined` function which represents
diff --git a/lib/mix/lib/mix/tasks/profile.tprof.ex b/lib/mix/lib/mix/tasks/profile.tprof.ex
@@ -125,7 +125,7 @@ defmodule Mix.Tasks.Profile.Tprof do
   ## Caveats
 
   You should be aware that the code being profiled is running in an anonymous
-  function which is invoked by [`:tprof` module](https://www.erlang.org/doc/man/tprof.html).
+  function which is invoked by [`:tprof` module](`:tprof`).
   Thus, you'll see some additional entries in your profile output. It is also
   important to note that the profiler is stopped as soon as the code has finished running,
   and this may need special attention, when: running asynchronous code as function calls which were
diff --git a/lib/mix/lib/mix/tasks/release.ex b/lib/mix/lib/mix/tasks/release.ex
@@ -167,8 +167,8 @@ defmodule Mix.Tasks.Release do
       $ bin/RELEASE_NAME daemon
 
   In daemon mode, the system is started on the background via
-  [`run_erl`](https://www.erlang.org/doc/apps/erts/run_erl_cmd.html). You may also
-  want to enable [`heart`](https://www.erlang.org/doc/man/heart.html)
+  [`run_erl`](https://www.erlang.org/doc/apps/erts/run_erl_cmd.html).
+  You may also want to enable [`:heart`](`:heart`)
   in daemon mode so it automatically restarts the system in case
   of crashes. See the generated `releases/RELEASE_VSN/env.sh` file.
 
diff --git a/lib/mix/lib/mix/tasks/test.coverage.ex b/lib/mix/lib/mix/tasks/test.coverage.ex
@@ -11,9 +11,9 @@ defmodule Mix.Tasks.Test.Coverage do
 
   ## Line coverage
 
-  Elixir uses Erlang's [`:cover`](https://www.erlang.org/doc/man/cover.html)
-  for its default test coverage. Erlang coverage is done by tracking
-  *executable lines of code*. This implies blank lines, code comments,
+  Elixir uses Erlang's [`:cover`](`:cover`) for its default test coverage.
+  Erlang coverage is done by tracking *executable lines of code*.
+  This implies blank lines, code comments,
   function signatures, and patterns are not necessarily executable and
   therefore won't be tracked in coverage reports. Code in macros are
   also often executed at compilation time, and therefore may not be covered.
