update rust toolchain to latest nightly

Signed-off-by: Gavin Inglis <[email protected]>

Author: ginglis13

rust-toolchain.toml

@@ -2,5 +2,5 @@
 # particular date of the nightly compiler, but we want builds to be reproducable, so we lock to a
 # specific, recent instance of nightly.
 [toolchain]
-channel = "nightly-2024-07-11"
+channel = "nightly-2025-02-24"
 profile = "default"

tools/buildsys/src/cache.rs

@@ -159,7 +159,7 @@ impl LookasideCache {
         let name = parsed
             .path_segments()
             .context(error::ExternalFileNameSnafu { path: url })?
-            .last()
+            .next_back()
             .context(error::ExternalFileNameSnafu { path: url })?;
         Ok(name.into())
     }

tools/buildsys/src/gomod.rs

@@ -162,7 +162,7 @@ fn extract_file_name(url: &str) -> Result<PathBuf> {
     let name = parsed
         .path_segments()
         .context(error::InputFileBadSnafu { path: url })?
-        .last()
+        .next_back()
         .context(error::InputFileBadSnafu { path: url })?;
     Ok(name.into())
 }

tools/oci-cli-wrapper/src/lib.rs

@@ -3,14 +3,14 @@
 //!
 //! Current two tools are supported:
 //! * crane, gcrane, krane
-//!     Crane provides a more direct interaction with the container registry,
-//!     allowing us to query image information in the registry without having to pull the full image to
-//!     disk. It also does not require a daemon to operate and has optimizations for pulling large images to disk
+//!   Crane provides a more direct interaction with the container registry,
+//!   allowing us to query image information in the registry without having to pull the full image to
+//!   disk. It also does not require a daemon to operate and has optimizations for pulling large images to disk
 //! * docker
-//!     Docker can perform all interactions we need with several caveats that make it less efficient than
-//!     crane. The image needs to be pulled locally in order for docker to inspect the manifest and extract
-//!     metadata. In addition, in order to operate with OCI image format, the containerd-snapshotter
-//!     feature has to be enabled in the docker daemon
+//!   Docker can perform all interactions we need with several caveats that make it less efficient than
+//!   crane. The image needs to be pulled locally in order for docker to inspect the manifest and extract
+//!   metadata. In addition, in order to operate with OCI image format, the containerd-snapshotter
+//!   feature has to be enabled in the docker daemon
 use std::fmt::{Display, Formatter};
 use std::{collections::HashMap, path::Path};
 

tools/testsys/src/aws_resources.rs

@@ -114,8 +114,8 @@ pub(crate) struct AmiImage {
 }
 
 /// Create a CRD to launch Bottlerocket instances on an EKS or ECS cluster.
-pub(crate) async fn ec2_crd<'a>(
-    bottlerocket_input: BottlerocketInput<'a>,
+pub(crate) async fn ec2_crd(
+    bottlerocket_input: BottlerocketInput<'_>,
     cluster_type: ClusterType,
     region: &str,
 ) -> Result<Resource> {
@@ -231,8 +231,8 @@ pub(crate) async fn ec2_crd<'a>(
 }
 
 /// Create a CRD to launch Bottlerocket instances on an EKS or ECS cluster.
-pub(crate) async fn ec2_karpenter_crd<'a>(
-    bottlerocket_input: BottlerocketInput<'a>,
+pub(crate) async fn ec2_karpenter_crd(
+    bottlerocket_input: BottlerocketInput<'_>,
     region: &str,
 ) -> Result<Resource> {
     let cluster_name = bottlerocket_input

tools/testsys/src/crds.rs

@@ -36,7 +36,7 @@ pub struct CrdInput<'a> {
     pub images: TestsysImages,
 }
 
-impl<'a> CrdInput<'a> {
+impl CrdInput<'_> {
     /// Retrieve the TUF repo information from `Infra.toml`
     pub fn tuf_repo_config(&self) -> Option<TufRepoConfig> {
         if let (Some(metadata_base_url), Some(targets_url)) = (

tools/update-metadata/src/lib.rs

@@ -311,7 +311,7 @@ impl Update {
             .waves
             .range((Included(0), Excluded(seed)))
             .map(|(k, v)| (*k, *v))
-            .last();
+            .next_back();
         let end_wave = self
             .waves
             .range((Included(seed), Included(MAX_SEED)))

twoliter/src/project/lock/mod.rs

@@ -1,7 +1,7 @@
-/// Covers the functionality and implementation of Twoliter.lock which is generated using
-/// `twoliter update`. It acts similarly to Cargo.lock as a flattened out representation of all kit
-/// and sdk image dependencies with associated digests so twoliter can validate that contents of a kit
-/// do not mutate unexpectedly.
+//! Covers the functionality and implementation of Twoliter.lock which is generated using
+//! `twoliter update`. It acts similarly to Cargo.lock as a flattened out representation of all kit
+//! and sdk image dependencies with associated digests so twoliter can validate that contents of a kit
+//! do not mutate unexpectedly.
 
 /// Contains operations for working with an OCI Archive
 mod archive;

twoliter/src/project/lock/verification.rs

@@ -101,9 +101,6 @@ impl LockfileVerifier for Lock {
     }
 }
 
-/// A `LockfileVerifier` can return a set of `VerifyTag` structs, claiming that those artifacts
-/// have been resolved and verified against the lockfile.
-
 /// Writes marker files indicating which artifacts have been resolved and verified against the lock
 #[derive(Debug)]
 pub(crate) struct VerificationTagger {

twoliter/src/project/vendor.rs

@@ -98,7 +98,7 @@ impl OverriddenVendor {
             .unwrap_or(&self.original_vendor.registry)
     }
 
-    pub(crate) fn repo_for<'a, V: VendedArtifact>(&'a self, image: &'a V) -> &str {
+    pub(crate) fn repo_for<'a, V: VendedArtifact>(&'a self, image: &'a V) -> &'a str {
         self.override_
             .name
             .as_deref()