chore: fix clippy

compiler/hash-ast/src/lib.rs

@@ -1,6 +1,6 @@
 //! Hash Compiler AST library file
 
-#![feature(box_into_inner, iter_intersperse, let_chains, lazy_cell)]
+#![feature(box_into_inner, iter_intersperse, let_chains)]
 
 pub mod ast;
 pub mod node_map;

compiler/hash-attrs/src/lib.rs

@@ -1,6 +1,6 @@
 //! All of the defined logic and data structures for attribute management in the
 //! Hash compiler.
-#![feature(lazy_cell, let_chains, macro_metavar_expr)]
+#![feature(let_chains, macro_metavar_expr)]
 
 pub mod attr;
 pub mod builtin;

compiler/hash-codegen/src/lib.rs

@@ -4,12 +4,12 @@
 //! available backends are the following:
 //!
 //! 1. The LLVM backend which translates Hash IR into LLVM IR so that it can be
-//! compiled by LLVM into a native executable with the specified target
-//! triple. The LLVM backend is located in the `hash-codegen-llvm` crate.
+//!    compiled by LLVM into a native executable with the specified target
+//!    triple. The LLVM backend is located in the `hash-codegen-llvm` crate.
 //!
 //! 2. The bytecode backend which translates Hash IR into Hash Bytecode so that
-//! it can be processed by the Hash VM. The bytecode backend is located in the
-//! `hash-codegen-bytecode` crate.
+//!    it can be processed by the Hash VM. The bytecode backend is located in
+//!    the `hash-codegen-bytecode` crate.
 //!
 //! A backend that implements the `CodeGen` trait can be used to generate code
 //! for a specific target, and then the compiler plumbing will continue after

compiler/hash-codegen/src/lower/locals.rs

@@ -176,15 +176,14 @@ impl<'ir, 'a, 'b, Builder: BlockBuilderMethods<'a, 'b>> LocalKindAnalyser<'ir, '
     /// change the previous kind of memory with the following rules:
     ///
     /// - If the previous kind of memory was a [LocalMemoryKind::Zst] or
-    /// [LocalMemoryKind::Memory] then no changes occur since these cannot
-    /// in any way be promoted.
+    ///   [LocalMemoryKind::Memory] then no changes occur since these cannot in
+    ///   any way be promoted.
     ///
-    /// - If the previous kind of memory is [LocalMemoryKind::Unused] then it
-    /// is converted into a [LocalMemoryKind::Ssa] with an associated [IrRef].
+    /// - If the previous kind of memory is [LocalMemoryKind::Unused] then it is
+    ///   converted into a [LocalMemoryKind::Ssa] with an associated [IrRef].
     ///
-    /// - If the previous kind of memory is [LocalMemoryKind::SSA] then it
-    /// is converted into a [LocalMemoryKind::Memory] since it is no longer
-    /// SSA.
+    /// - If the previous kind of memory is [LocalMemoryKind::SSA] then it is
+    ///   converted into a [LocalMemoryKind::Memory] since it is no longer SSA.
     pub fn assign(&mut self, local: Local, reference: ir::IrRef) {
         let local_kind = &mut self.locals[local];
 

compiler/hash-codegen/src/lower/mod.rs

@@ -71,16 +71,16 @@ pub struct FnBuilder<'a, 'b, Builder: BlockBuilderMethods<'a, 'b>> {
     /// the following:
     ///
     /// 1. The type of the local must be judged as an "immediate" by the
-    /// backend.
+    ///    backend.
     ///
     /// 2. The operand should not be referenced indirectly:
     ///
     ///    - It's address should not be taken by the `&` operator.
     ///
-    ///   - It cannot appear in a projection (e.g. `x.field`).
+    ///    - It cannot appear in a projection (e.g. `x.field`).
     ///
     /// 3. The operand must be defined by an [ir::RValue] that can generate
-    /// immediate values as judged by [`Self::rvalue_creates_operand`].
+    ///    immediate values as judged by [`Self::rvalue_creates_operand`].
     locals: IndexVec<Local, LocalRef<Builder::Value>>,
 
     /// A map that denotes the "lowering" status of each block from an
@@ -126,15 +126,15 @@ impl<'a, 'b, Builder: BlockBuilderMethods<'a, 'b>> FnBuilder<'a, 'b, Builder> {
 /// This is the main entry point for converting the IR body into the
 /// target backend. The process is as follows:
 ///
-/// 1. Analyse what locals are declared and what kind of locals they
-/// are. This is done so that we can avoid allocating space on the stack
-/// for locals that are possibly immediate values or just temporaries.
+/// 1. Analyse what locals are declared and what kind of locals they are. This
+///    is done so that we can avoid allocating space on the stack for locals
+///    that are possibly immediate values or just temporaries.
 ///
-/// 2. Generate debug information for the function, and any of the locals
-/// that are used within the function.
+/// 2. Generate debug information for the function, and any of the locals that
+///    are used within the function.
 ///
-/// 3. Traverse the control flow graph in post-order and generate each
-/// block in the function.
+/// 3. Traverse the control flow graph in post-order and generate each block in
+///    the function.
 pub fn codegen_body<'a, 'b, Builder: BlockBuilderMethods<'a, 'b>>(
     instance: InstanceId,
     body: &'b ir::Body,

compiler/hash-codegen/src/lower/terminator.rs

@@ -60,11 +60,10 @@ impl<'a, 'b, Builder: BlockBuilderMethods<'a, 'b>> FnBuilder<'a, 'b, Builder> {
     /// with the next block. The conditions for merging two blocks
     /// must be:
     ///
-    /// 1. The current block must be the only predecessor of the next
-    ///   block.
+    /// 1. The current block must be the only predecessor of the next block.
     ///
-    /// 2. The current block must only have a single successor which
-    /// leads to the block that is a candidate for merging.
+    /// 2. The current block must only have a single successor which leads to
+    ///    the block that is a candidate for merging.
     pub(super) fn codegen_terminator(
         &mut self,
         builder: &mut Builder,

compiler/hash-codegen/src/symbols/mangle.rs

@@ -8,21 +8,18 @@
 //! identify the function in the generated object file. The
 //! mangling algorithm first deals with the following cases:
 //!
-//! 1. If the function is not generic, then the mangle symbol
-//! name is the same as the function name, with the module
-//! path prepended as a namespace that is relative to the
-//! entry_point module.
+//! 1. If the function is not generic, then the mangle symbol name is the same
+//!    as the function name, with the module path prepended as a namespace that
+//!    is relative to the entry_point module.
 //!
-//! 2. If the function is generic, the type parameters of the
-//! function are needed to create a unique name such that they
-//! distinguish the function from other functions with the same
-//! name. The type parameters are encoded into the final symbol
-//! name.
+//! 2. If the function is generic, the type parameters of the function are
+//!    needed to create a unique name such that they distinguish the function
+//!    from other functions with the same name. The type parameters are encoded
+//!    into the final symbol name.
 //!
-//!
-//! 3. If there are any attributes that are set on the instance
-//! which prevent the function function from being "mangled", then
-//! we have to avoid mangling the symbol name.
+//! 3. If there are any attributes that are set on the instance which prevent
+//!    the function function from being "mangled", then we have to avoid
+//!    mangling the symbol name.
 
 use hash_attrs::builtin::attrs;
 use hash_ir::ty::{InstanceHelpers, InstanceId};

compiler/hash-link/src/linker/gcc.rs

@@ -66,8 +66,8 @@ impl<'ctx> GccLinker<'ctx> {
 
     /// Check whether the linker takes hints, specifically:
     ///
-    /// - macOS does not take hints since it does not rely on
-    /// `binutils` to perform linking.
+    /// - macOS does not take hints since it does not rely on `binutils` to
+    ///   perform linking.
     fn takes_hints(&self) -> bool {
         self.is_ld && self.is_gnu && !self.settings.target().is_like_osx()
     }

compiler/hash-lower/src/build/matches/candidate.rs

@@ -7,9 +7,9 @@
 //! full range of patterns (most of this will go away with the new
 //! pattern representation). Notably, the following problems persist:
 //!
-//! 1. `if-guards` that are located on sub-patterns are not properly
-//! handled, it is assumed there is an outermost 'if-guard' that is
-//! used to determine the control flow, amongst other things.
+//! 1. `if-guards` that are located on sub-patterns are not properly handled, it
+//!    is assumed there is an outermost 'if-guard' that is used to determine the
+//!    control flow, amongst other things.
 
 use std::{borrow::Borrow, mem};
 

compiler/hash-lower/src/optimise/cleanup_locals.rs

@@ -5,8 +5,7 @@
 //! 1. Count how many times the [Local] is used as an [RValue].
 //!
 //! 2. For any [Local]s that are to be removed, we also remove all assignments
-//!    to those locals that may affect counts of other
-//!   [Local]s.
+//!    to those locals that may affect counts of other [Local]s.
 
 use hash_ir::{
     ir::{

compiler/hash-pipeline/src/settings.rs

@@ -153,8 +153,8 @@ impl CompilerSettings {
     ///    entry point with an appended `out` directory.
     ///
     /// 3. If the user has not specified an entry point, use the operating
-    /// system    temporary directory with an appended `hash-#session-id`
-    /// directory.
+    ///    system temporary directory with an appended `hash-#session-id`
+    ///    directory.
     pub fn output_directory(&self) -> Result<PathBuf, PipelineError> {
         // For the `temp` directory case, we want to create a folder within the
         // temporary directory that is unique to this session.

compiler/hash-repr/src/compute.rs

@@ -368,15 +368,15 @@ impl<'l> LayoutComputer<'l> {
     /// 1. Compute the layout of all of the fields of the type.
     ///
     /// 2. push all of the ZST-like fields to the start of the struct to avoid
-    /// dealing with them between other fields.
+    ///    dealing with them between other fields.
     ///
     /// 3. Sort the remaining fields in order of "effective" alignment of each
-    /// field, essentially the largest fields by size and alignment are
-    /// grouped first, and then descending down.
+    ///    field, essentially the largest fields by size and alignment are
+    ///    grouped first, and then descending down.
     ///
     /// 4. try and optimise the ABI of the given type to represent it as a
-    /// scalar which means it can reach more optimisations when code is
-    /// generated for this kind.
+    ///    scalar which means it can reach more optimisations when code is
+    ///    generated for this kind.
     ///
     /// N.B. If layout optimisations are not applicable, then steps 2-3 are not
     /// applied.
@@ -678,15 +678,15 @@ impl<'l> LayoutComputer<'l> {
     /// 1. Figure out the type layout of the enum "prefix" tag.
     ///
     /// 2. Compute the layouts of each variant sub-structure, with the applied
-    /// prefix offset.
+    ///    prefix offset.
     ///
     /// 3. Check if the tag can be neatly aligned with the smallest alignment
-    /// from all the variants, which means that the tag is expanded to align
-    /// the type and avoid redundant padding being created when performing
-    /// `load` / `store` operations.
+    ///    from all the variants, which means that the tag is expanded to align
+    ///    the type and avoid redundant padding being created when performing
+    ///    `load` / `store` operations.
     ///
     /// 4. Attempt to optimise the ABI of the enum by looking at if it can be
-    /// represented as a scalar value.
+    ///    represented as a scalar value.
     ///
     /// 5. Then, collect all of the variant layouts, and build the final layout.
     fn compute_layout_of_enum(

compiler/hash-repr/src/write.rs

@@ -4,8 +4,8 @@
 //! @@Improvements:
 //!
 //! 1. Since the layout printer is only a shallow printer, an improvement could
-//! be made to print the layout of the types that are nested within the type,
-//! and possibly exploring the nested structure:
+//!    be made to print the layout of the types that are nested within the type,
+//!    and possibly exploring the nested structure:
 //! ```notrust
 //! struct Item (
 //!    item: ( #layout_of (y: i32, x: i32), z: [i32; 3]

compiler/hash-semantics/src/passes/discovery/discriminants.rs

@@ -31,7 +31,7 @@ impl<'env, E: SemanticEnv> DiscoveryPass<'env, E> {
     /// The algorithm follows the following rules:
     ///
     /// 1. If the enum has a `repr` attribute, then we use the type that is
-    ///   specified in the attribute.
+    ///    specified in the attribute.
     ///
     /// 2. Otherwise, loop over all of the variants, and find the largest
     ///    discriminant value.

compiler/hash-source/src/lib.rs

@@ -1,5 +1,5 @@
 //! Hash Compiler source location definitions.
-#![feature(path_file_prefix, let_chains, lazy_cell, const_trait_impl, box_patterns, const_option)]
+#![feature(path_file_prefix, let_chains, const_trait_impl, box_patterns, const_option)]
 
 pub mod constant;
 pub mod entry_point;

compiler/hash-utils/src/scoping/mod.rs

@@ -8,12 +8,15 @@
 //! and a member index.
 //!
 //! The context is parameterized by three types:
+//!
 //! - `ScopeKind`: The type of the scope kind. This is used to distinguish
-//!  different kinds of scopes, e.g. a module scope vs. a function scope.
+//!   different kinds of scopes, e.g. a module scope vs. a function scope.
+//!
 //! - `Value`: The type of the value associated with each member.
-//! - `Symbol`: The type of the symbol associated with each member.
-//! These types are collected into a `ContextTypes` trait, which is then
-//! used as a bound on all relevant structures.
+//!
+//! - `Symbol`: The type of the symbol associated with each member. These types
+//!   are collected into a `ContextTypes` trait, which is then used as a bound
+//!   on all relevant structures.
 use std::{
     fmt::Debug,
     hash::{Hash, Hasher},