Conversation
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis 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. |
BenchmarksComparisonBenchmark execution time: 2026-03-05 15:34:32 Comparing candidate commit 682eca3 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 57 metrics, 2 unstable metrics. CandidateCandidate benchmark detailsGroup 1
Group 2
Group 3
Group 4
Group 5
Group 6
Group 7
Group 8
Group 9
Group 10
Group 11
Group 12
Group 13
Group 14
Group 15
Group 16
Group 17
Group 18
Group 19
BaselineOmitted due to size. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1661 +/- ##
==========================================
- Coverage 71.24% 71.22% -0.03%
==========================================
Files 427 428 +1
Lines 62805 63275 +470
==========================================
+ Hits 44748 45065 +317
- Misses 18057 18210 +153
🚀 New features to boost your workflow:
|
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
81de782 to
682eca3
Compare
paullegranddc
left a comment
There was a problem hiding this comment.
The code is a bit verbose but LGTM overall
| // Macros (local copies, matching trace_exporter.rs pattern) | ||
| // --------------------------------------------------------------------------- | ||
|
|
||
| macro_rules! gen_error { |
There was a problem hiding this comment.
There are better ways to share the defs than copying the macros, but I guess it doesn't matter if we're going to throw away the code
| out_low: &mut u64, | ||
| out_high: &mut u64, |
There was a problem hiding this comment.
The doc should point out that out_low and out_high should be initialized memory so people don't do this
uint64_t high, low;
// should be this so the refs are initialized
// uint64_t high = 0, low = 0;
ddog_tracer_span_get_trace_id(handle, &low, &high)
| // --------------------------------------------------------------------------- | ||
| // Span getters (for reading field values back to C / Ruby) | ||
| // --------------------------------------------------------------------------- |
There was a problem hiding this comment.
I added those for some tests: https://github.com/DataDog/dd-trace-rb/pull/5422/changes#diff-41c54aacdd9cf0c9f8adf9d5610bda1b5abadf1a09e629ffb8ff3578b0b178b3R195
While full black box testing works, these help a lot to identify where and how things break.
From experience with libddwaf which lacked getters for the longest time and needed some gnarly gdb inspection, getters definitely come handy a lot at a minimum for logging/debugging/testing, even when unused in production codepaths.
I do think we might need them in the future in a couple of actual production codepath places but I'll have to check. Not an immediate need though.
| /// | ||
| /// Returns an error if the slice is not valid UTF-8. | ||
| #[inline] | ||
| fn charslice_to_bytesstring(s: CharSlice) -> Result<BytesString, Box<ExporterError>> { |
There was a problem hiding this comment.
Not sure BytesString is the right type here because it's kind of inneficient but this is a refactor for us common component rather than for you
There was a problem hiding this comment.
As long as it doesn't structurally compromise a future evolution I'm fine with using something a bit slower.
Make it work, make it right, make it fast!
What does this PR do?
add necessary bits to build and expose the trace API for Ruby's trace exporter
Motivation
Getting the ball rolling on discussion with actual code
Additional Notes
DO NOT MERGE
How to test the change?
See DataDog/dd-trace-rb#5422