Fix misuse of *usage* throughout Reference prose

*Usage* means a customary pattern of use (as in "regional usage
varies") or a rate or quantity of use (as in "disk usage").  It
doesn't mean *use*.  Whenever *use* works, *usage* shouldn't appear.

Let's fix each incorrect use of *usage* -- i.e., adopt better *usage*
of *usage* -- throughout the prose of the Reference.

Author: traviscross

src/attributes.md

@@ -223,7 +223,7 @@ The following is an index of all built-in attributes.
   - [`automatically_derived`] --- Marker for implementations created by `derive`.
 
 - Macros
-  - [`macro_export`] --- Exports a `macro_rules` macro for cross-crate usage.
+  - [`macro_export`] --- Exports a `macro_rules` macro for cross-crate use.
   - [`macro_use`] --- Expands macro visibility, or imports macros from other crates.
   - [`proc_macro`] --- Defines a function-like macro.
   - [`proc_macro_derive`] --- Defines a derive macro.

src/attributes/codegen.md

@@ -274,7 +274,7 @@ r[attributes.codegen.target_feature.x86]
 #### `x86` or `x86_64`
 
 Executing code with unsupported features is undefined behavior on this platform.
-Hence on this platform usage of `#[target_feature]` functions follows the
+Hence on this platform use of `#[target_feature]` functions follows the
 [above restrictions][attributes.codegen.target_feature.safety-restrictions].
 
 Feature     | Implicitly Enables | Description
@@ -399,7 +399,7 @@ Feature     | Implicitly Enables | Description
 r[attributes.codegen.target_feature.aarch64]
 #### `aarch64`
 
-On this platform the usage of `#[target_feature]` functions follows the
+On this platform the use of `#[target_feature]` functions follows the
 [above restrictions][attributes.codegen.target_feature.safety-restrictions].
 
 Further documentation on these features can be found in the [ARM Architecture
@@ -462,7 +462,7 @@ Feature        | Implicitly Enables | Feature Name
 r[attributes.codegen.target_feature.loongarch]
 #### `loongarch`
 
-On this platform the usage of `#[target_feature]` functions follows the
+On this platform the use of `#[target_feature]` functions follows the
 [above restrictions][attributes.codegen.target_feature.safety-restrictions].
 
 Feature     | Implicitly Enables  | Description
@@ -488,7 +488,7 @@ Feature     | Implicitly Enables  | Description
 r[attributes.codegen.target_feature.riscv]
 #### `riscv32` or `riscv64`
 
-On this platform the usage of `#[target_feature]` functions follows the
+On this platform the use of `#[target_feature]` functions follows the
 [above restrictions][attributes.codegen.target_feature.safety-restrictions].
 
 Further documentation on these features can be found in their respective

src/attributes/diagnostics.md

@@ -261,7 +261,7 @@ lints that would otherwise warn within the entity.
 fn example_err() {
     // This is an error because the `unsafe_code` warning has
     // been lifted to "deny".
-    unsafe { an_unsafe_fn() } // ERROR: usage of `unsafe` block
+    unsafe { an_unsafe_fn() } // ERROR: use of `unsafe` block
 }
 ```
 
@@ -304,7 +304,7 @@ r[attributes.diagnostics.deprecated]
 
 r[attributes.diagnostics.deprecated.intro]
 The *`deprecated` attribute* marks an item as deprecated. `rustc` will issue
-warnings on usage of `#[deprecated]` items. `rustdoc` will show item
+warnings on use of `#[deprecated]` items. `rustdoc` will show item
 deprecation, including the `since` version and `note`, if available.
 
 r[attributes.diagnostics.deprecated.syntax]

src/inline-assembly.md

@@ -183,7 +183,7 @@ unsafe { core::arch::asm!("/* {x} */"); } // ERROR: no argument named x
 ```
 
 r[asm.ts-args.one-or-more]
-An `asm!` invocation may have one or more template string arguments; an `asm!` with multiple template string arguments is treated as if all the strings were concatenated with a `\n` between them. The expected usage is for each template string argument to correspond to a line of assembly code.
+An `asm!` invocation may have one or more template string arguments; an `asm!` with multiple template string arguments is treated as if all the strings were concatenated with a `\n` between them. The expected use is for each template string argument to correspond to a line of assembly code.
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {

src/items/constant-items.md

@@ -11,7 +11,7 @@ r[items.const.intro]
 A *constant item* is an optionally named _[constant value]_ which is not associated with a specific memory location in the program.
 
 r[items.const.behavior]
-Constants are essentially inlined wherever they are used, meaning that they are copied directly into the relevant context when used. This includes usage of constants from external crates, and non-[`Copy`] types. References to the same constant are not necessarily guaranteed to refer to the same memory address.
+Constants are essentially inlined wherever they are used, meaning that they are copied directly into the relevant context when used. This includes use of constants from external crates, and non-[`Copy`] types. References to the same constant are not necessarily guaranteed to refer to the same memory address.
 
 r[items.const.namespace]
 The constant declaration defines the constant value in the [value namespace] of the module or block where it is located.

src/items/use-declarations.md

@@ -201,7 +201,7 @@ mod example {
 ```
 
 > [!NOTE]
-> `self` may also be used as the first segment of a path. The usage of `self` as the first segment and inside a `use` brace is logically the same; it means the current module of the parent segment, or the current module if there is no parent segment. See [`self`] in the paths chapter for more information on the meaning of a leading `self`.
+> `self` may also be used as the first segment of a path. The use of `self` as the first segment and inside a `use` brace is logically the same; it means the current module of the parent segment, or the current module if there is no parent segment. See [`self`] in the paths chapter for more information on the meaning of a leading `self`.
 
 r[items.use.self.namespace]
 `self` only creates a binding from the [type namespace] of the parent entity. For example, in the following, only the `foo` mod is imported:

src/linkage.md

@@ -14,7 +14,7 @@ found in the [FFI section of the book][ffi].
 
 r[link.type]
 In one session of compilation, the compiler can generate multiple artifacts
-through the usage of either command line flags or the `crate_type` attribute.
+through the use of either command line flags or the `crate_type` attribute.
 If one or more command line flags are specified, all `crate_type` attributes will
 be ignored in favor of only building the artifacts specified by command line.
 

src/names/namespaces.md

@@ -4,7 +4,7 @@ r[names.namespaces]
 r[names.namespaces.intro]
 A *namespace* is a logical grouping of declared [names]. Names are segregated into separate namespaces based on the kind of entity the name refers to. Namespaces allow the occurrence of a name in one namespace to not conflict with the same name in another namespace.
 
-There are several different namespaces that each contain different kinds of entities. The usage of a name will look for the declaration of that name in different namespaces, based on the context, as described in the [name resolution] chapter.
+There are several different namespaces that each contain different kinds of entities. The use of a name will look for the declaration of that name in different namespaces, based on the context, as described in the [name resolution] chapter.
 
 r[names.namespaces.kinds]
 The following is a list of namespaces, with their corresponding entities: