Fix misuse of *usage* throughout the Reference

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/generics.md

@@ -56,7 +56,7 @@ The const identifier introduces a name in the [value namespace] for the constant
 r[items.generics.const.allowed-types]
 The only allowed types of const parameters are `u8`, `u16`, `u32`, `u64`, `u128`, `usize`, `i8`, `i16`, `i32`, `i64`, `i128`, `isize`, `char` and `bool`.
 
-r[items.generics.const.usage]
+r[items.generics.const.use]
 Const parameters can be used anywhere a [const item] can be used, with the exception that when used in a [type] or [array repeat expression], it must be standalone (as described below). That is, they are allowed in the following places:
 
 1. As an applied const to any type which forms a part of the signature of the item in question.

src/items/implementations.md

@@ -188,7 +188,7 @@ impl Seq<bool> for u32 {
 }
 ```
 
-r[items.impl.generics.usage]
+r[items.impl.generics.use]
 Generic parameters *constrain* an implementation if the parameter appears at least once in one of:
 
 * The implemented trait, if it has one

src/items/unions.md

@@ -180,7 +180,7 @@ fn test() {
 }
 ```
 
-r[items.union.ref.usage]
+r[items.union.ref.use]
 As you could see, in many aspects (except for layouts, safety, and ownership) unions behave exactly like structs, largely as a consequence of inheriting their syntactic shape from structs. This is also true for many unmentioned aspects of Rust language (such as privacy, name resolution, type inference, generics, trait implementations, inherent implementations, coherence, pattern checking, etc etc etc).
 
 [`transmute`]: std::mem::transmute

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:

src/patterns.md

@@ -61,7 +61,7 @@ if let
 }
 ```
 
-r[patterns.usage]
+r[patterns.use]
 Patterns are used in:
 
 r[patterns.let]

src/types/boolean.md

@@ -20,13 +20,13 @@ An object with the boolean type has a [size and alignment] of 1 each.
 r[type.bool.repr]
 The value false has the bit pattern `0x00` and the value true has the bit pattern `0x01`. It is [undefined behavior] for an object with the boolean type to have any other bit pattern.
 
-r[type.bool.usage]
+r[type.bool.use]
 The boolean type is the type of many operands in various [expressions]:
 
-r[type.bool.usage-condition]
+r[type.bool.use-in-condition]
 * The condition operand in [if expressions] and [while expressions]
 
-r[type.bool.usage-lazy-operator]
+r[type.bool.use-in-lazy-operator]
 * The operands in [lazy boolean operator expressions][lazy]
 
 > [!NOTE]

src/visibility-and-privacy.md

@@ -56,7 +56,7 @@ These two cases are surprisingly powerful for creating module hierarchies exposi
 
 In the second case, it mentions that a private item "can be accessed" by the current module and its descendants, but the exact meaning of accessing an item depends on what the item is.
 
-r[vis.usage]
+r[vis.use]
 Accessing a module, for example, would mean looking inside of it (to import more items). On the other hand, accessing a function would mean that it is invoked. Additionally, path expressions and import statements are considered to access an item in the sense that the import/expression is only valid if the destination is in the current visibility scope.
 
 Here's an example of a program which exemplifies the three cases outlined above: