feat(ci): run clippy on wasm target by Eldolfin · Pull Request #2184 · DataDog/libdatadog

Eldolfin · 2026-07-01T12:08:23Z

What does this PR do?

A brief description of the change being made with this pull request.

Motivation

We don't run tests for wasm so we should at least ensure it's lint free to try to catch bugs early

Additional Notes

Anything else we should know when reviewing?

How to test the change?

Describe here in detail how the change can be validated.

datadog-datadog-us1-prod · 2026-07-01T12:23:15Z

Tests

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 3 Pipeline jobs failed

Lint | clippy #wasm nightly

Lint | clippy #wasm stable

Required checks pass | allchecks

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 66.67%
• Overall Coverage: 74.45% (+0.14%)

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: a82209f | Docs | Datadog PR Page | Give us feedback!}

dd-octo-sts · 2026-07-01T12:42:45Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	85.64 MB	85.64 MB	+0% (+32 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	7.88 MB	7.88 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.60 MB	10.60 MB	0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	96.81 MB	96.81 MB	+0% (+32 B) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	25.41 MB	25.41 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	88.04 KB	88.04 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	184.51 MB	184.51 MB	+0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	945.48 MB	945.48 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.29 MB	8.29 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	88.04 KB	88.04 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	24.52 MB	24.52 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	48.85 MB	48.85 MB	0% (0 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.02 MB	22.02 MB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	89.42 KB	89.42 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	188.52 MB	188.53 MB	+0% (+8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	932.67 MB	932.67 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.41 MB	6.41 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	89.42 KB	89.42 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	26.32 MB	26.32 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	46.48 MB	46.48 MB	0% (0 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	76.38 MB	76.38 MB	0% (0 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.76 MB	8.76 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	91.86 MB	91.86 MB	0% (0 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.66 MB	10.66 MB	0% (0 B) 👌

…-wasm

Aaalibaba42 · 2026-07-01T16:15:49Z

I'm not sure we actually want to do this. It's natural to have parameters that become unused or other kinds of lints that trigger on a secondary platform, and handling this would pollute the code a lot more that it would help imho.

For instance if we allow maybe_unused on stuff that isn't used only by wasm, it's error prone for native if every it really becomes unused, and forcing it be used by all platforms can be detrimental or require heavy refactor

Eldolfin · 2026-07-01T16:28:03Z

I still have to clean it up a bit but I'll soon push the lint fixes, it's not that bad actually and some of it gets fixed by your PRs

For me the motivation is that we don't run tests for wasm so we should at least ensure it's lint free to try to catch bugs early.

github-actions · 2026-07-02T09:59:29Z

📚 Documentation Check Results

⚠️ 1392 documentation warning(s) found

📦 `libdd-data-pipeline` - 1204 warning(s)

📦 `libdd-shared-runtime` - 188 warning(s)

Updated: 2026-07-02 14:02:25 UTC | Commit: b5050e7 | missing-docs job results

github-actions · 2026-07-02T10:00:23Z

Clippy Allow Annotation Report

Comparing clippy allow annotations between branches:

Base Branch: origin/main
PR Branch: origin/oscarld/ci-clippy-wasm

Summary by Rule

Rule	Base Branch	PR Branch	Change
unwrap_used	2	2	No change (0%)
Total	2	2	No change (0%)

Annotation Counts by File

File	Base Branch	PR Branch	Change
`libdd-data-pipeline/src/trace_exporter/mod.rs`	2	2	No change (0%)

Annotation Stats by Crate

Crate	Base Branch	PR Branch	Change
`clippy-annotation-reporter`	5	5	No change (0%)
`datadog-ffe-ffi`	1	1	No change (0%)
`datadog-ipc`	22	22	No change (0%)
`datadog-live-debugger`	4	4	No change (0%)
`datadog-live-debugger-ffi`	10	10	No change (0%)
`datadog-profiling-replayer`	4	4	No change (0%)
`datadog-sidecar`	45	45	No change (0%)
`libdd-common`	13	13	No change (0%)
`libdd-common-ffi`	12	12	No change (0%)
`libdd-data-pipeline`	6	6	No change (0%)
`libdd-ddsketch`	2	2	No change (0%)
`libdd-dogstatsd-client`	1	1	No change (0%)
`libdd-profiling`	13	13	No change (0%)
`libdd-remote-config`	3	3	No change (0%)
`libdd-telemetry`	20	20	No change (0%)
`libdd-tinybytes`	4	4	No change (0%)
`libdd-trace-normalization`	2	2	No change (0%)
`libdd-trace-obfuscation`	3	3	No change (0%)
`libdd-trace-stats`	1	1	No change (0%)
`libdd-trace-utils`	11	11	No change (0%)
Total	182	182	No change (0%)

About This Report

This report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality.

github-actions · 2026-07-02T10:01:07Z

🔒 Cargo Deny Results

⚠️ 3 issue(s) found, showing only errors (advisories, bans, sources)

📦 `libdd-data-pipeline` - 2 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:218:1
    │
218 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.0.0
      │   ├── libdd-capabilities-impl v2.0.0
      │   │   ├── libdd-data-pipeline v6.0.0
      │   │   ├── libdd-shared-runtime v1.0.0
      │   │   │   ├── libdd-data-pipeline v6.0.0 (*)
      │   │   │   ├── libdd-telemetry v5.0.1
      │   │   │   │   ├── libdd-data-pipeline v6.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v5.0.0
      │   │   │   │       └── libdd-data-pipeline v6.0.0 (*)
      │   │   │   └── libdd-trace-stats v5.0.0 (*)
      │   │   ├── libdd-trace-stats v5.0.0 (*)
      │   │   └── libdd-trace-utils v8.0.0
      │   │       ├── libdd-data-pipeline v6.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v4.0.0
      │   │       │   └── libdd-trace-stats v5.0.0 (*)
      │   │       ├── libdd-trace-stats v5.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v8.0.0 (*)
      │   ├── libdd-data-pipeline v6.0.0 (*)
      │   ├── libdd-dogstatsd-client v3.0.0
      │   │   ├── libdd-data-pipeline v6.0.0 (*)
      │   │   └── libdd-trace-stats v5.0.0 (*)
      │   ├── libdd-shared-runtime v1.0.0 (*)
      │   ├── libdd-telemetry v5.0.1 (*)
      │   ├── libdd-trace-obfuscation v4.0.0 (*)
      │   ├── libdd-trace-stats v5.0.0 (*)
      │   └── libdd-trace-utils v8.0.0 (*)
      ├── (dev) libdd-data-pipeline v6.0.0 (*)
      ├── (dev) libdd-ddsketch v1.0.1
      │   ├── libdd-data-pipeline v6.0.0 (*)
      │   ├── libdd-telemetry v5.0.1 (*)
      │   └── libdd-trace-stats v5.0.0 (*)
      ├── (dev) libdd-trace-normalization v2.0.0
      │   ├── libdd-data-pipeline v6.0.0 (*)
      │   └── libdd-trace-utils v8.0.0 (*)
      ├── (dev) libdd-trace-stats v5.0.0 (*)
      ├── libdd-trace-utils v8.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── libdd-data-pipeline v6.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v8.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:287:1
    │
287 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v6.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-shared-runtime` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:73:1
   │
73 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.0.0
         ├── libdd-capabilities-impl v2.0.0
         │   └── libdd-shared-runtime v1.0.0
         └── libdd-shared-runtime v1.0.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-07-02 14:04:01 UTC | Commit: b5050e7 | dependency-check job results

danielsn · 2026-07-06T19:26:41Z

+          RUSTUP_TOOLCHAIN: ${{ steps.install-toolchain.outputs.version }}
+        run: |
+          # List of crates that are meant to be compilable for wasm.
+          WASM_ALLOWLIST="build_common cc_utils datadog-ffe datadog-ffe-test-suite datadog-ipc-macros datadog-sidecar-macros libdd-capabilities libdd-common libdd-data-pipeline libdd-ddsketch libdd-dogstatsd-client libdd-log libdd-otel-thread-ctx libdd-otel-thread-ctx-ffi libdd-profiling-protobuf libdd-remote-config libdd-sampling libdd-shared-runtime libdd-tinybytes libdd-trace-normalization libdd-trace-obfuscation libdd-trace-protobuf libdd-trace-stats libdd-trace-utils sidecar_mockgen"


How will we keep this in sync?

Not sure honestly, the other idea I had instead of a fixed list would be to add a metadata field to each relevant crate's Cargo.toml to indicate if it should be compiling on wasm but that would add more complexity and I'm not even sure it solve the syncing problem, it just moves it to a per-crate toggle.

I'm open to suggestion if you have a better alternative in mind

danielsn · 2026-07-06T19:29:20Z

+#[cfg(not(target_arch = "wasm32"))]
+pub(crate) type WorkerRegistry = std::sync::Arc<Mutex<Vec<WorkerEntry>>>;
+#[cfg(target_arch = "wasm32")]
+pub(crate) type WorkerRegistry = std::rc::Rc<Mutex<Vec<WorkerEntry>>>;


Why do we need the mutex if single-threaded?

danielsn · 2026-07-06T19:29:22Z

+// single-threaded and its workers are `!Send`, so `Rc` is both correct and avoids the
+// `arc_with_non_send_sync` lint.
+#[cfg(not(target_arch = "wasm32"))]
+pub(crate) type WorkerRegistry = std::sync::Arc<Mutex<Vec<WorkerEntry>>>;


Will this pattern recur? Should this be a generic type?

feat(ci): run clippy on wasm target

0e1bf5d

github-actions Bot added the ci-build label Jul 1, 2026

Eldolfin added 4 commits July 1, 2026 15:04

fix: --target wasm and limit to wasm compatible crates

906038b

fix(ci): install wasm32 target for the toolchain under test in clippy…

a0cdedf

…-wasm

fix: add crates that compile with --no-default-features

b4bf49b

fix: add crates that compile with --no-default-features

7747b8d

fix lints

b5e56fc

github-actions Bot added the data-pipeline label Jul 2, 2026

fix: lints

a82209f

danielsn reviewed Jul 6, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(ci): run clippy on wasm target#2184

feat(ci): run clippy on wasm target#2184
Eldolfin wants to merge 7 commits into
mainfrom
oscarld/ci-clippy-wasm

Eldolfin commented Jul 1, 2026 •

edited

Loading

Uh oh!

datadog-datadog-us1-prod Bot commented Jul 1, 2026 •

edited by datadog-prod-us1-5 Bot

Loading

Uh oh!

dd-octo-sts Bot commented Jul 1, 2026 •

edited

Loading

Uh oh!

Aaalibaba42 commented Jul 1, 2026

Uh oh!

Eldolfin commented Jul 1, 2026

Uh oh!

github-actions Bot commented Jul 2, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jul 2, 2026

Uh oh!

github-actions Bot commented Jul 2, 2026 •

edited

Loading

Uh oh!

danielsn Jul 6, 2026

Uh oh!

Eldolfin Jul 7, 2026

Uh oh!

danielsn Jul 6, 2026

Uh oh!

danielsn Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Eldolfin commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Additional Notes

How to test the change?

Uh oh!

datadog-datadog-us1-prod Bot commented Jul 1, 2026 • edited by datadog-prod-us1-5 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Warnings

ℹ️ Info

Uh oh!

dd-octo-sts Bot commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

Aaalibaba42 commented Jul 1, 2026

Uh oh!

Eldolfin commented Jul 1, 2026

Uh oh!

github-actions Bot commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 libdd-data-pipeline - 1204 warning(s)

📦 libdd-shared-runtime - 188 warning(s)

Uh oh!

github-actions Bot commented Jul 2, 2026

Clippy Allow Annotation Report

Summary by Rule

Annotation Counts by File

Annotation Stats by Crate

About This Report

Uh oh!

github-actions Bot commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 libdd-data-pipeline - 2 error(s)

📦 libdd-shared-runtime - 1 error(s)

Uh oh!

danielsn Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

Eldolfin Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

danielsn Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

danielsn Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Eldolfin commented Jul 1, 2026 •

edited

Loading

datadog-datadog-us1-prod Bot commented Jul 1, 2026 •

edited by datadog-prod-us1-5 Bot

Loading

dd-octo-sts Bot commented Jul 1, 2026 •

edited

Loading

github-actions Bot commented Jul 2, 2026 •

edited

Loading

📦 `libdd-data-pipeline` - 1204 warning(s)

📦 `libdd-shared-runtime` - 188 warning(s)

github-actions Bot commented Jul 2, 2026 •

edited

Loading

📦 `libdd-data-pipeline` - 2 error(s)

📦 `libdd-shared-runtime` - 1 error(s)