Fix link and image reference definitions and remove unused link and image reference definitions

Author: ShapelessCat

src/doc/src/guide/cargo-toml-vs-cargo-lock.md

@@ -101,4 +101,3 @@ that the argument to `cargo update` is actually a
 short specification.
 
 [def-manifest]:  ../appendix/glossary.md#manifest  '"manifest" (glossary entry)'
-[def-package]:   ../appendix/glossary.md#package   '"package" (glossary entry)'

src/doc/src/reference/build-scripts.md

@@ -128,7 +128,7 @@ one detailed below.
 * [`cargo::rustc-env=VAR=VALUE`](#rustc-env) --- Sets an environment variable.
 * [`cargo::rustc-cdylib-link-arg=FLAG`](#rustc-cdylib-link-arg) --- Passes custom
   flags to a linker for cdylib crates.
-- [`cargo::error=MESSAGE`](#cargo-error) --- Displays an error on the terminal.
+* [`cargo::error=MESSAGE`](#cargo-error) --- Displays an error on the terminal.
 * [`cargo::warning=MESSAGE`](#cargo-warning) --- Displays a warning on the
   terminal.
 * [`cargo::metadata=KEY=VALUE`](#the-links-manifest-key) --- Metadata, used by `links`
@@ -439,11 +439,11 @@ key-value pairs. This metadata is set with the `cargo::metadata=KEY=VALUE`
 instruction.
 
 The metadata is passed to the build scripts of **dependent** packages. For
-example, if the package `foo` depends on `bar`, which links `baz`, then if 
+example, if the package `foo` depends on `bar`, which links `baz`, then if
 `bar` generates `key=value` as part of its build script metadata, then the
 build script of `foo` will have the environment variables `DEP_BAZ_KEY=value`
 (note that the value of the `links` key is used).
-See the ["Using another `sys` crate"][using-another-sys] for an example of 
+See the ["Using another `sys` crate"][using-another-sys] for an example of
 how this can be used.
 
 Note that metadata is only passed to immediate dependents, not transitive

src/doc/src/reference/cargo-targets.md

@@ -313,7 +313,6 @@ name = "my-pg-tool"
 required-features = ["postgres", "tools"]
 ```
 
-
 ## Target auto-discovery
 
 By default, Cargo automatically determines the targets to build based on the
@@ -379,7 +378,6 @@ autobins = false
 [`cargo test`]: ../commands/cargo-test.md
 [cfg-test]: ../../reference/conditional-compilation.html#test
 [crate types]: ../../reference/linkage.html
-[crates.io]: https://crates.io/
 [customized]: #configuring-a-target
 [dependencies]: specifying-dependencies.md
 [dev-dependencies]: specifying-dependencies.md#development-dependencies

src/doc/src/reference/environment-variables.md

@@ -163,8 +163,6 @@ In summary, the supported environment variables are:
 [`build.incremental`]: config.md#buildincremental
 [`build.dep-info-basedir`]: config.md#builddep-info-basedir
 [`doc.browser`]: config.md#docbrowser
-[`cargo-new.name`]: config.md#cargo-newname
-[`cargo-new.email`]: config.md#cargo-newemail
 [`cargo-new.vcs`]: config.md#cargo-newvcs
 [`future-incompat-report.frequency`]: config.md#future-incompat-reportfrequency
 [`http.debug`]: config.md#httpdebug

src/doc/src/reference/external-tools.md

@@ -12,7 +12,6 @@ facilities:
 
 * support for custom subcommands.
 
-
 ## Information about package structure
 
 You can use [`cargo metadata`] command to get information about package
@@ -63,7 +62,6 @@ messages.
 > **MSRV:** 1.77 is required for `package_id` to be a Package ID Specification. Before that, it was opaque.
 
 [build command documentation]: ../commands/cargo-build.md
-[cargo_metadata]: https://crates.io/crates/cargo_metadata
 [Package ID Specifications]: ./pkgid-spec.md
 
 ### Compiler messages
@@ -303,7 +301,4 @@ approach has drawbacks:
 
 Instead, it is encouraged to use the CLI interface to drive Cargo. The [`cargo
 metadata`] command can be used to obtain information about the current project
-(the [`cargo_metadata`] crate provides a Rust interface to this command).
-
-[`cargo metadata`]: ../commands/cargo-metadata.md
-[`cargo_metadata`]: https://crates.io/crates/cargo_metadata
+(the [cargo_metadata] crate provides a Rust interface to this command).

src/doc/src/reference/features-examples.md

@@ -90,7 +90,7 @@ Some packages provide bindings to common C libraries (sometimes referred to as
 C library installed on the system, or to build it from source. For example,
 the [`openssl`] package has a [`vendored` feature][openssl-vendored] which
 enables the corresponding `vendored` feature of [`openssl-sys`]. The
-`openssl-sys` build script has some [conditional logic][openssl-sys-cfg] which
+`openssl-sys` [build script] has some [conditional logic][openssl-sys-cfg] which
 causes it to build from a local copy of the OpenSSL source code instead of
 using the version from the system.
 
@@ -162,7 +162,6 @@ features.
 The [`simd_support` feature][rand-simd_support] of the [`rand`] package is another example,
 which relies on a dependency that only builds on the nightly channel.
 
-[`wasm-bindgen`]: https://crates.io/crates/wasm-bindgen
 [nightly channel]: ../../book/appendix-07-nightly-rust.html
 [wasm-bindgen-nightly]: https://github.com/rustwasm/wasm-bindgen/blob/0.2.69/Cargo.toml#L27
 [wasm-bindgen-unsize]: https://github.com/rustwasm/wasm-bindgen/blob/0.2.69/src/closure.rs#L257-L269

src/doc/src/reference/manifest.md

@@ -91,7 +91,7 @@ a keyword. [crates.io] imposes even more restrictions, such as:
 
 ### The `version` field
 
-The `version` field is formatted according to the [SemVer] specification:
+The `version` field is formatted according to the [Semantic Versioning] specification:
 
 Versions must have three numeric parts,
 the major version, the minor version, and the patch version.
@@ -105,18 +105,18 @@ For example, `1.0.0-alpha.11` is higher than `1.0.0-alpha.4`.
 A metadata part can be added after a plus, such as `1.0.0+21AF26D3`.
 This is for informational purposes only and is generally ignored by Cargo.
 
-Cargo bakes in the concept of [Semantic Versioning](https://semver.org/),
-so versions are considered considered [compatible](semver.md) if their left-most non-zero major/minor/patch component is the same.
-See the [Resolver] chapter for more information on how Cargo uses versions to
-resolve dependencies.
+Cargo bakes in the concept of [Semantic Versioning], so versions are considered
+[compatible] if their left-most non-zero major/minor/patch component is the
+same.  See the [Resolver] chapter for more information on how Cargo uses
+versions to resolve dependencies.
 
 This field is optional and defaults to `0.0.0`.  The field is required for publishing packages.
 
 > **MSRV:** Before 1.75, this field was required
 
-[SemVer]: https://semver.org
+[Semantic Versioning]: https://semver.org
 [Resolver]: resolver.md
-[SemVer compatibility]: semver.md
+[compatible]: semver.md
 
 ### The `authors` field
 
@@ -612,8 +612,6 @@ The `[profile]` tables provide a way to customize compiler settings such as
 optimizations and debug settings. See [the Profiles chapter](profiles.md) for
 more detail.
 
-
-
 [`cargo init`]: ../commands/cargo-init.md
 [`cargo new`]: ../commands/cargo-new.md
 [`cargo package`]: ../commands/cargo-package.md

src/doc/src/reference/overriding-dependencies.md

@@ -353,7 +353,6 @@ changes.
 > crates that have been published to [crates.io]. You cannot use this feature
 > to tell Cargo how to find local unpublished crates.
 
-
 [crates.io]: https://crates.io/
 [multiple locations]: specifying-dependencies.md#multiple-locations
 [dependencies]: specifying-dependencies.md

src/doc/src/reference/profiles.md

@@ -382,18 +382,18 @@ The profile used depends on the command, the command-line flags like
 | Command | Default Profile |
 |---------|-----------------|
 | [`cargo run`], [`cargo build`],<br>[`cargo check`], [`cargo rustc`] | [`dev` profile](#dev) |
-| [`cargo test`] | [`test` profile](#test)
-| [`cargo bench`] | [`bench` profile](#bench)
-| [`cargo install`] | [`release` profile](#release)
+| [`cargo test`] | [`test` profile](#test) |
+| [`cargo bench`] | [`bench` profile](#bench) |
+| [`cargo install`] | [`release` profile](#release) |
 
 You can switch to a different profile using the `--profile=NAME` option which will used the given profile.
 The `--release` flag is equivalent to `--profile=release`.
 
-The selected profile applies to all Cargo targets, 
+The selected profile applies to all Cargo targets,
 including [library](./cargo-targets.md#library),
-[binary](./cargo-targets.md#binaries), 
-[example](./cargo-targets.md#examples), 
-[test](./cargo-targets.md#tests), 
+[binary](./cargo-targets.md#binaries),
+[example](./cargo-targets.md#examples),
+[test](./cargo-targets.md#tests),
 and [benchmark](./cargo-targets.md#benchmarks).
 
 The profile for specific packages can be specified with

src/doc/src/reference/publishing.md

@@ -285,7 +285,6 @@ request the org owner to do so.
 [`cargo publish`]: ../commands/cargo-publish.md
 [`categories`]: manifest.md#the-categories-field
 [`description`]: manifest.md#the-description-field
-[`documentation`]: manifest.md#the-documentation-field
 [`homepage`]: manifest.md#the-homepage-field
 [`keywords`]: manifest.md#the-keywords-field
 [`license` or `license-file`]: manifest.md#the-license-and-license-file-fields

src/doc/src/reference/registries.md

@@ -124,13 +124,11 @@ controlled via the [`registries.crates-io.protocol`] config key.
 [Credential Provider Protocol]: credential-provider-protocol.md
 [Registry Authentication]: registry-authentication.md
 [`cargo publish`]: ../commands/cargo-publish.md
-[`cargo package`]: ../commands/cargo-package.md
 [`cargo login`]: ../commands/cargo-login.md
 [config]: config.md
 [crates.io]: https://crates.io/
 [`registries.crates-io.protocol`]: config.md#registriescrates-ioprotocol
 
-
 <script>
 (function() {
     var fragments = {

src/doc/src/reference/registry-index.md

@@ -39,7 +39,6 @@ The keys are:
   all operations to be authenticated including API requests, crate downloads
   and sparse index updates.
 
-
 ## Download Endpoint
 The download endpoint should send the `.crate` file for the requested package.
 Cargo supports https, http, and file URLs, HTTP redirects, HTTP1 and HTTP2.
@@ -319,7 +318,6 @@ the equivalent git URL when the sparse protocol is used.
 If a registry does offer both protocols, it's currently recommended to choose one protocol
 as the canonical protocol and use [source replacement] for the other protocol.
 
-
 [`cargo publish`]: ../commands/cargo-publish.md
 [alphanumeric]: ../../std/primitive.char.html#method.is_alphanumeric
 [crates.io]: https://crates.io/

src/doc/src/reference/registry-web-api.md

@@ -354,9 +354,5 @@ The "login" endpoint is not an actual API request. It exists solely for the
 browser to log in and retrieve an API token.
 
 [`cargo login`]: ../commands/cargo-login.md
-[`cargo package`]: ../commands/cargo-package.md
-[`cargo publish`]: ../commands/cargo-publish.md
-[alphanumeric]: ../../std/primitive.char.html#method.is_alphanumeric
-[config]: config.md
 [crates.io]: https://crates.io/
 [publishing documentation]: publishing.md#cargo-owner

src/doc/src/reference/resolver.md

@@ -390,7 +390,6 @@ situations:
 
 [build-dependencies]: specifying-dependencies.md#build-dependencies
 [dev-dependencies]: specifying-dependencies.md#development-dependencies
-[resolver-field]: features.md#resolver-versions
 
 ### `links`
 
@@ -466,7 +465,6 @@ all platforms are enabled. In other words, the resolver ignores the platform
 or `cfg` expression.
 
 [build]: specifying-dependencies.md#build-dependencies
-[dev-dependencies]: specifying-dependencies.md#development-dependencies
 [Platform-specific dependencies]: specifying-dependencies.md#platform-specific-dependencies
 
 ### dev-dependency cycles
@@ -647,8 +645,6 @@ The use of open-ended version requirements like `>=0.6` is discouraged in Cargo.
 But, if you run into this situation, the [`cargo update`] command with the
 `--precise` flag can be used to manually remove such duplications.
 
-[`cargo update`]: ../commands/cargo-update.md
-
 ### Why wasn't a newer version selected?
 
 Say you noticed that the latest version of a dependency wasn't selected when you ran:

src/doc/src/reference/running-a-registry.md

@@ -16,5 +16,4 @@ for a list of what is available.
 
 [Registry Web API]: registry-web-api.md
 [Registry Index]: registry-index.md
-[`cargo publish`]: ../commands/cargo-publish.md
 [`cargo package`]: ../commands/cargo-package.md

src/doc/src/reference/semver.md

@@ -2310,7 +2310,6 @@ document what your commitments are.
 [items]: ../../reference/items.html
 [non_exhaustive]: ../../reference/attributes/type_system.html#the-non_exhaustive-attribute
 [object safe]: ../../reference/items/traits.html#object-safety
-[rust-feature]: https://doc.rust-lang.org/nightly/unstable-book/
 [sealed trait]: https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed
 [SemVer]: https://semver.org/
 [struct literal]: ../../reference/expressions/struct-expr.html

src/doc/src/reference/specifying-dependencies.md

@@ -50,7 +50,7 @@ This is different from [SemVer] which considers all pre-1.0.0 packages to be inc
 
 ### Caret requirements
 
-**Caret requirements** are the default version requirement strategy. 
+**Caret requirements** are the default version requirement strategy.
 This version strategy allows [SemVer] compatible updates.
 They are specified as version requirements with a leading caret (`^`).
 
@@ -213,7 +213,7 @@ regex = { git = "https://github.com/rust-lang/regex.git" }
 ```
 
 Cargo fetches the `git` repository at that location and traverses the file tree to find
-`Cargo.toml` file for the requested crate anywhere inside the `git` repository. 
+`Cargo.toml` file for the requested crate anywhere inside the `git` repository.
 For example, `regex-lite` and `regex-syntax` are members of `rust-lang/regex` repo
 and can be referred to by the repo's root URL (`https://github.com/rust-lang/regex.git`)
 regardless of where in the file tree they reside.
@@ -240,7 +240,7 @@ regex = { git = "https://github.com/rust-lang/regex.git", branch = "next" }
 
 Anything that is not a branch or a tag falls under `rev` key. This can be a commit
 hash like `rev = "4c59b707"`, or a named reference exposed by the remote
-repository such as `rev = "refs/pull/493/head"`. 
+repository such as `rev = "refs/pull/493/head"`.
 
 What references are available for the `rev` key varies by where the repo is hosted.  
 GitHub exposes a reference to the most recent commit of every pull request as in the example above.
@@ -280,7 +280,7 @@ The `version` key always implies that the package is available in a registry,
 regardless of the presence of `git` or `path` keys.
 
 The `version` key does _not_ affect which commit is used when Cargo retrieves the `git` dependency,
-but Cargo checks the version information in the dependency's `Cargo.toml` file 
+but Cargo checks the version information in the dependency's `Cargo.toml` file
 against the `version` key and raises an error if the check fails.
 
 In this example, Cargo retrieves the HEAD commit of the branch called `next` from Git and checks if the crate's version
@@ -291,7 +291,7 @@ is compatible with `version = "1.10.3"`:
 regex = { version = "1.10.3", git = "https://github.com/rust-lang/regex.git", branch = "next" }
 ```
 
-`version`, `git`, and `path` keys are considered separate locations for resolving the dependency. 
+`version`, `git`, and `path` keys are considered separate locations for resolving the dependency.
 See [Multiple locations](#multiple-locations) section below for detailed explanations.
 
 > **Note**: [crates.io] does not allow packages to be published with
@@ -519,7 +519,6 @@ manifest:
 cc = "1.0.3"
 ```
 
-
 You can also have target-specific build dependencies by using
 `build-dependencies` in the target section header instead of `dependencies`. For
 example:
@@ -647,7 +646,6 @@ cc.workspace = true
 rand = { workspace = true, optional = true }
 ```
 
-
 [SemVer]: https://semver.org
 [crates.io]: https://crates.io/
 [dev-dependencies]: #development-dependencies

src/doc/src/reference/timings.md

@@ -1,4 +1,5 @@
 # Reporting build timings
+
 The `--timings` option gives some information about how long each compilation
 takes, and tracks concurrency information over time.
 
@@ -12,20 +13,20 @@ filename, if you want to look at older runs.
 
 ## Reading the graphs
 
-There are two tables and two graphs in the output. 
+There are two tables and two graphs in the output.
 
-The first table displays the build information of the project, including the 
-number of units built, the maximum number of concurrency, build time, and the 
+The first table displays the build information of the project, including the
+number of units built, the maximum number of concurrency, build time, and the
 version information of the currently used compiler.
 
 ![build-info](../images/build-info.png)
 
 The "unit" graph shows the duration of each unit over time. A "unit" is a single
-compiler invocation. There are lines that show which additional units are 
-"unlocked" when a unit finishes. That is, it shows the new units that are now 
+compiler invocation. There are lines that show which additional units are
+"unlocked" when a unit finishes. That is, it shows the new units that are now
 allowed to run because their dependencies are all finished. Hover the mouse over
-a unit to highlight the lines. This can help visualize the critical path of 
-dependencies. This may change between runs because the units may finish in 
+a unit to highlight the lines. This can help visualize the critical path of
+dependencies. This may change between runs because the units may finish in
 different orders.
 
 The "codegen" times are highlighted in a lavender color. In some cases, build

src/doc/src/reference/unstable.md

@@ -1992,4 +1992,3 @@ about specifying custom cfgs.
 The 2024 edition has been stabilized in the 1.85 release.
 See the [`edition` field](manifest.md#the-edition-field) for more information on setting the edition.
 See [`cargo fix --edition`](../commands/cargo-fix.md) and [The Edition Guide](../../edition-guide/index.html) for more information on migrating existing projects.
-