Skip to content

chore(clippy): add workspace lints string_slice, await_holding_lock, let_underscore_must_use#25669

Open
pront wants to merge 2 commits into
masterfrom
pront/workspace-clippy-lints
Open

chore(clippy): add workspace lints string_slice, await_holding_lock, let_underscore_must_use#25669
pront wants to merge 2 commits into
masterfrom
pront/workspace-clippy-lints

Conversation

@pront

@pront pront commented Jun 23, 2026

Copy link
Copy Markdown
Member

Motivation

A recent bug (#25582) was caused by byte-indexing into a &str that could contain multi-byte UTF-8 characters. Clippy's string_slice lint would have caught it. This PR enables that lint — plus two other high-value lints — across the entire workspace.

Changes

Adds to [workspace.lints.clippy]:

  • string_slice — flags &str[n..] byte-index slicing that can panic on multi-byte boundaries
  • await_holding_lock — flags .await while holding a MutexGuard (potential deadlock)
  • let_underscore_must_use — flags let _ = expr where the return value is #[must_use]

All existing violations are resolved. Where a clean API exists (strip_prefix, split_once, .ok()), that's used. #[expect] is reserved for cases where the index is provably on a char boundary (e.g., indices from find() on ASCII chars, or char_indices()).

Also incidentally fixes a latent panic in the aws_kinesis sink where partition_key[..256] could panic on multi-byte keys; replaced with floor_char_boundary(256).

…let_underscore_must_use

Adds three opt-in clippy lints to [workspace.lints.clippy] so they apply
across all workspace crates:

- string_slice: catches &str[n..] byte-index slicing that can panic on
  multi-byte UTF-8 boundaries (the direct cause of the bug fixed in #25582)
- await_holding_lock: catches .await while holding a MutexGuard (potential
  deadlock)
- let_underscore_must_use: catches let _ = expr where expr has a #[must_use]
  type or return value

All existing violations are resolved: real fixes preferred (strip_prefix,
split_once, split_at, .ok()), with targeted #[expect] or #![allow] reserved
for provably-safe patterns (regex/find() indices, Derivative macro false
positives) and one genuine unavoidable case (kinesis partition_key truncation
via floor_char_boundary).

Also fixes a latent panic in aws_kinesis sink: partition_key[..256] could
panic on multi-byte keys; replaced with floor_char_boundary(256).
@pront pront requested review from a team as code owners June 23, 2026 20:11
@github-actions github-actions Bot added domain: sources Anything related to the Vector's sources domain: transforms Anything related to Vector's transform components domain: sinks Anything related to the Vector's sinks domain: core Anything related to core crates i.e. vector-core, core-common, etc domain: vdev Anything related to the vdev tooling labels Jun 23, 2026
@datadog-vectordotdev

datadog-vectordotdev Bot commented Jun 23, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: ccd384c | Docs | Give us feedback!

@pront pront added the no-changelog Changes in this PR do not need user-facing explanations in the release changelog label Jun 23, 2026
Comment on lines 142 to +148
if !input.starts_with('@') || input.len() < 2 {
return Err(ParseError::Malformed(
"expected non empty '@'-prefixed sampling component",
));
}

let num: f64 = input[1..].parse()?;
let num: f64 = input.strip_prefix('@').unwrap().parse()?;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can reassign input here by calling input.strip_prefix('@') instead of input.starts_with('@'). This way we avoid the unwrap call. Same applies for other usages of strip_prefix().unwrap()

Comment thread lib/codecs/Cargo.toml

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For libs that are using custom lints like this one I think it's best that we use

[lints]
workspace = true

and add #![deny(clippy::unwrap_used)] in lib.rs so that workspace lints never fall out of date

Affected tomls:

  • lib/codecs/Cargo.toml
  • lib/dnsmsg-parser/Cargo.toml
  • lib/tracing-limit/Cargo.toml
  • lib/vector-core/Cargo.toml

Comment on lines +439 to +444
write!(acc, "[{sd_id}").ok();
for (key, value) in sd_params {
let esc_val = escape_sd_value(value);
let _ = write!(acc, " {key}=\"{esc_val}\"");
write!(acc, " {key}=\"{esc_val}\"").ok();
}
let _ = write!(acc, "]");
write!(acc, "]").ok();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably use push_str + format here to avoid .ok()s

Suggested change
write!(acc, "[{sd_id}").ok();
for (key, value) in sd_params {
let esc_val = escape_sd_value(value);
let _ = write!(acc, " {key}=\"{esc_val}\"");
write!(acc, " {key}=\"{esc_val}\"").ok();
}
let _ = write!(acc, "]");
write!(acc, "]").ok();
acc.push_str("[{sd_id}");
for (key, value) in sd_params {
let esc_val = escape_sd_value(value);
acc.push_str(&format!(" {key}=\"{esc_val}\""));
}
acc.push_str("]");

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain: core Anything related to core crates i.e. vector-core, core-common, etc domain: sinks Anything related to the Vector's sinks domain: sources Anything related to the Vector's sources domain: transforms Anything related to Vector's transform components domain: vdev Anything related to the vdev tooling no-changelog Changes in this PR do not need user-facing explanations in the release changelog

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants