ci: fix newer clippy lints

Author: Firestar99

.cargo/config.toml

@@ -45,7 +45,6 @@ rustflags = [
     "-Wclippy::match_wild_err_arm",
     "-Wclippy::match_wildcard_for_single_variants",
     "-Wclippy::mem_forget",
-    "-Wclippy::mismatched_target_os",
     "-Wclippy::missing_enforced_import_renames",
     "-Wclippy::mut_mut",
     "-Wclippy::mutex_integer",

spirv-tools-sys/src/assembler.rs

@@ -25,7 +25,7 @@ pub enum DisassembleOptions {
     NoHeader = 0x20,
     /// Use friendly names where possible.  The heuristic may expand over
     /// time, but will use common names for scalar types, and debug names from
-    /// OpName instructions.
+    /// `OpName` instructions.
     FriendlyNames = 0x40,
     /// Add some comments to the generated assembly
     Comment = 0x80,
@@ -41,7 +41,7 @@ extern "C" {
     /// by the context's target environment.
     ///
     /// The options parameter is a bit field of
-    /// spv_text_to_binary_options_t.
+    /// `spv_text_to_binary_options_t`.
     #[link_name = "spvTextToBinaryWithOptions"]
     pub fn assemble(
         tool: *const shared::ToolContext,
@@ -53,8 +53,8 @@ extern "C" {
     ) -> shared::SpirvResult;
 
     /// Decodes the given SPIR-V binary representation to its assembly text. The
-    /// word_count parameter specifies the number of words for binary. The options
-    /// parameter is a bit field of spv_binary_to_text_options_t. Decoded text will
+    /// `word_count` parameter specifies the number of words for binary. The options
+    /// parameter is a bit field of `spv_binary_to_text_options_t`. Decoded text will
     /// be stored into *text. Any error will be written into *diagnostic if
     /// diagnostic is non-null, otherwise the context's message consumer will be
     /// used.

spirv-tools-sys/src/opt.rs

@@ -26,33 +26,33 @@ pub enum TargetEnv {
     Vulkan_1_0,
     /// SPIR-V 1.1 latest revision, no other restrictions.
     Universal_1_1,
-    /// OpenCL Full Profile 2.1 latest revision.
+    /// `OpenCL` Full Profile 2.1 latest revision.
     OpenCL_2_1,
-    /// OpenCL Full Profile 2.2 latest revision.
+    /// `OpenCL` Full Profile 2.2 latest revision.
     OpenCL_2_2,
-    /// OpenGL 4.0 plus GL_ARB_gl_spirv, latest revisions.
+    /// OpenGL 4.0 plus `GL_ARB_gl_spirv`, latest revisions.
     OpenGL_4_0,
-    /// OpenGL 4.1 plus GL_ARB_gl_spirv, latest revisions.
+    /// OpenGL 4.1 plus `GL_ARB_gl_spirv`, latest revisions.
     OpenGL_4_1,
-    /// OpenGL 4.2 plus GL_ARB_gl_spirv, latest revisions.
+    /// OpenGL 4.2 plus `GL_ARB_gl_spirv`, latest revisions.
     OpenGL_4_2,
-    /// OpenGL 4.3 plus GL_ARB_gl_spirv, latest revisions.
+    /// OpenGL 4.3 plus `GL_ARB_gl_spirv`, latest revisions.
     OpenGL_4_3,
-    /// OpenGL 4.5 plus GL_ARB_gl_spirv, latest revisions.
+    /// OpenGL 4.5 plus `GL_ARB_gl_spirv`, latest revisions.
     OpenGL_4_5,
     /// SPIR-V 1.2, latest revision, no other restrictions.
     Universal_1_2,
-    /// OpenCL Full Profile 1.2 plus cl_khr_il_program, latest revision.
+    /// `OpenCL` Full Profile 1.2 plus `cl_khr_il_program`, latest revision.
     OpenCL_1_2,
-    /// OpenCL Embedded Profile 1.2 plus cl_khr_il_program, latest revision.
+    /// `OpenCL` Embedded Profile 1.2 plus `cl_khr_il_program`, latest revision.
     OpenCLEmbedded_1_2,
-    /// OpenCL Full Profile 2.0 plus cl_khr_il_program, latest revision.
+    /// `OpenCL` Full Profile 2.0 plus `cl_khr_il_program`, latest revision.
     OpenCL_2_0,
-    /// OpenCL Embedded Profile 2.0 plus cl_khr_il_program, latest revision.
+    /// `OpenCL` Embedded Profile 2.0 plus `cl_khr_il_program`, latest revision.
     OpenCLEmbedded_2_0,
-    /// OpenCL Embedded Profile 2.1 latest revision.
+    /// `OpenCL` Embedded Profile 2.1 latest revision.
     OpenCLEmbedded_2_1,
-    /// OpenCL Embedded Profile 2.2 latest revision.
+    /// `OpenCL` Embedded Profile 2.2 latest revision.
     OpenCLEmbedded_2_2,
     /// SPIR-V 1.3 latest revision, no other restrictions.
     Universal_1_3,
@@ -62,7 +62,7 @@ pub enum TargetEnv {
     WebGPU_0,
     /// SPIR-V 1.4 latest revision, no other restrictions.
     Universal_1_4,
-    /// Vulkan 1.1 with VK_KHR_spirv_1_4, i.e. SPIR-V 1.4 binary.
+    /// Vulkan 1.1 with `VK_KHR_spirv_1_4`, i.e. SPIR-V 1.4 binary.
     Vulkan_1_1_Spirv_1_4,
     /// SPIR-V 1.5 latest revision, no other restrictions.
     Universal_1_5,

spirv-tools-sys/src/shared.rs

@@ -78,19 +78,19 @@ extern "C" {
     /// if
     ///
     /// 1) the members of the structs are either the same type or are structs with
-    /// same layout, and
+    ///    same layout, and
     ///
     /// 2) the decorations that affect the memory layout are identical for both
-    /// types.  Other decorations are not relevant.
+    ///    types.  Other decorations are not relevant.
     #[link_name = "spvValidatorOptionsSetRelaxStoreStruct"]
     pub fn validator_options_set_relax_store_struct(opts: *mut ValidatorOptions, toggle: bool);
 
     /// Records whether or not the validator should relax the rules on pointer usage
     /// in logical addressing mode.
     ///
     /// When relaxed, it will allow the following usage cases of pointers:
-    /// 1) OpVariable allocating an object whose type is a pointer type
-    /// 2) OpReturnValue returning a pointer value
+    /// 1) `OpVariable` allocating an object whose type is a pointer type
+    /// 2) `OpReturnValue` returning a pointer value
     #[link_name = "spvValidatorOptionsSetRelaxLogicalPointer"]
     pub fn validator_options_set_relax_logical_pointer(opts: *mut ValidatorOptions, toggle: bool);
 
@@ -110,7 +110,7 @@ extern "C" {
 
     /// Records whether the validator should use "relaxed" block layout rules.
     /// Relaxed layout rules are described by Vulkan extension
-    /// VK_KHR_relaxed_block_layout, and they affect uniform blocks, storage blocks,
+    /// `VK_KHR_relaxed_block_layout`, and they affect uniform blocks, storage blocks,
     /// and push constants.
     ///
     /// This is enabled by default when targeting Vulkan 1.1 or later.
@@ -129,7 +129,7 @@ extern "C" {
     /// Records whether the validator should use "scalar" block layout rules.
     /// Scalar layout rules are more permissive than relaxed block layout.
     ///
-    /// See Vulkan extnesion VK_EXT_scalar_block_layout.  The scalar alignment is
+    /// See Vulkan extnesion `VK_EXT_scalar_block_layout`.  The scalar alignment is
     /// defined as follows:
     /// - scalar alignment of a scalar is the scalar size
     /// - scalar alignment of a vector is the scalar alignment of its component
@@ -138,9 +138,9 @@ extern "C" {
     /// - scalar alignment of a struct is the max scalar alignment among its
     ///   members
     ///
-    /// For a struct in Uniform, StorageClass, or PushConstant:
+    /// For a struct in Uniform, `StorageClass`, or `PushConstant`:
     /// - a member Offset must be a multiple of the member's scalar alignment
-    /// - ArrayStride or MatrixStride must be a multiple of the array or matrix
+    /// - `ArrayStride` or `MatrixStride` must be a multiple of the array or matrix
     ///   scalar alignment
     #[link_name = "spvValidatorOptionsSetScalarBlockLayout"]
     pub fn validator_options_set_scalar_block_layout(opts: *mut ValidatorOptions, toggle: bool);

spirv-tools-sys/src/val.rs

@@ -40,7 +40,7 @@ pub struct DisassembleOptions {
     pub no_header: bool,
     /// Use friendly names where possible.  The heuristic may expand over
     /// time, but will use common names for scalar types, and debug names from
-    /// OpName instructions.
+    /// `OpName` instructions.
     pub use_friendly_names: bool,
     /// Add some comments to the generated assembly
     pub comment: bool,

src/assembler.rs

@@ -37,7 +37,7 @@ impl From<CmdError> for crate::error::Error {
             } => {
                 // The C API just puts the last message as the diagnostic, so just do the
                 // same for now
-                let diagnostic = messages.into_iter().last().map_or_else(
+                let diagnostic = messages.into_iter().next_back().map_or_else(
                     || {
                         crate::error::Diagnostic::from(format!(
                             "tool exited with code `{exit_code}` and no output"

src/cmd.rs

@@ -13,17 +13,17 @@ pub struct ValidatorOptions {
     /// if
     ///
     /// 1) the members of the structs are either the same type or are structs with
-    /// same layout, and
+    ///    same layout, and
     ///
     /// 2) the decorations that affect the memory layout are identical for both
-    /// types.  Other decorations are not relevant.
+    ///    types.  Other decorations are not relevant.
     pub relax_struct_store: bool,
     /// Records whether or not the validator should relax the rules on pointer usage
     /// in logical addressing mode.
     ///
     /// When relaxed, it will allow the following usage cases of pointers:
-    /// 1) OpVariable allocating an object whose type is a pointer type
-    /// 2) OpReturnValue returning a pointer value
+    /// 1) `OpVariable` allocating an object whose type is a pointer type
+    /// 2) `OpReturnValue` returning a pointer value
     pub relax_logical_pointer: bool,
     /// Records whether or not the validator should relax the rules because it is
     /// expected that the optimizations will make the code legal.
@@ -39,7 +39,7 @@ pub struct ValidatorOptions {
     pub before_legalization: bool,
     /// Records whether the validator should use "relaxed" block layout rules.
     /// Relaxed layout rules are described by Vulkan extension
-    /// VK_KHR_relaxed_block_layout, and they affect uniform blocks, storage blocks,
+    /// `VK_KHR_relaxed_block_layout`, and they affect uniform blocks, storage blocks,
     /// and push constants.
     ///
     /// This is enabled by default when targeting Vulkan 1.1 or later.
@@ -51,7 +51,7 @@ pub struct ValidatorOptions {
     /// Records whether the validator should use "scalar" block layout rules.
     /// Scalar layout rules are more permissive than relaxed block layout.
     ///
-    /// See Vulkan extnesion VK_EXT_scalar_block_layout.  The scalar alignment is
+    /// See Vulkan extnesion `VK_EXT_scalar_block_layout`.  The scalar alignment is
     /// defined as follows:
     /// - scalar alignment of a scalar is the scalar size
     /// - scalar alignment of a vector is the scalar alignment of its component
@@ -60,9 +60,9 @@ pub struct ValidatorOptions {
     /// - scalar alignment of a struct is the max scalar alignment among its
     ///   members
     ///
-    /// For a struct in Uniform, StorageClass, or PushConstant:
+    /// For a struct in Uniform, `StorageClass`, or `PushConstant`:
     /// - a member Offset must be a multiple of the member's scalar alignment
-    /// - ArrayStride or MatrixStride must be a multiple of the array or matrix
+    /// - `ArrayStride` or `MatrixStride` must be a multiple of the array or matrix
     ///   scalar alignment
     pub scalar_block_layout: bool,
     /// Records whether or not the validator should skip validating standard

src/val.rs

@@ -90,7 +90,7 @@ fn main() {
         let _s = Group::new(&format!("adding '{td}' to $GITHUB_PATH ({gh_path:?})"));
 
         // emulate >> for both empty and non-empty files
-        let has_contents = fs::metadata(&gh_path).map_or(false, |md| md.len() > 0);
+        let has_contents = fs::metadata(&gh_path).is_ok_and(|md| md.len() > 0);
 
         let mut file = fs::OpenOptions::new()
             .append(true)

tools/install/main.rs

@@ -95,7 +95,7 @@ fn main() {
             };
 
             let name = if ext.is_empty() {
-                exe.to_string()
+                (*exe).to_string()
             } else {
                 format!("{exe}.{ext}")
             };