feat: change cargo patch approach to generic annotations#1634
Draft
Aaalibaba42 wants to merge 2 commits intojwiriath/capability-traits-architecturefrom
Draft
feat: change cargo patch approach to generic annotations#1634Aaalibaba42 wants to merge 2 commits intojwiriath/capability-traits-architecturefrom
Aaalibaba42 wants to merge 2 commits intojwiriath/capability-traits-architecturefrom
Conversation
📚 Documentation Check Results📦
|
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. |
🔒 Cargo Deny Results📦
|
bantonsson
reviewed
Mar 4, 2026
Contributor
bantonsson
left a comment
bantonsson
left a comment
There was a problem hiding this comment.
So I don't think this looks that terrible, and as you said bundling up the capabilities in some common type will ensure that it doesn't get too unwieldy.
| #[no_mangle] | ||
| pub unsafe extern "C" fn ddog_trace_exporter_new( | ||
| out_handle: NonNull<Box<TraceExporter>>, | ||
| out_handle: NonNull<Box<TraceExporter<DefaultHttpClient>>>, |
Contributor
There was a problem hiding this comment.
So this is just turbofish noise, since the builder isn't generic with the type and you need to repeat it below at the builder.build::<DefaultHttpClient>() call.
Either get the generic builder directly TraceExporterBuilder::default() or have the H propagate to the builder so we have builder.build() (which I prefer).
Contributor
Author
There was a problem hiding this comment.
If I make TraceExporterBuilder generic over H, I believe I'd be required to manually impl Default with a PhantomData<H> for perfect derive reasons, which seems worth it for how much boilerplate it shaves off, but yeah
…ot the builder itself
BenchmarksComparisonBenchmark execution time: 2026-03-04 14:09:12 Comparing candidate commit e0697b5 in PR branch Found 5 performance improvements and 2 performance regressions! Performance is the same for 50 metrics, 2 unstable metrics. scenario:credit_card/is_card_number/ 378282246310005
scenario:credit_card/is_card_number/378282246310005
scenario:credit_card/is_card_number_no_luhn/x371413321323331
scenario:single_flag_killswitch/rules-based
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. |
Aaalibaba42
force-pushed
the
jwiriath/capability-traits-architecture
branch
3 times, most recently
from
c299887 to
3dcd39b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Change cargo patch approach to generic annotations
Motivation
Discussions with the team about the best approach.
Additional Notes
Currently this is for 1 (one) capability, when we have 2, 3, or more capabilities, all these annations should either:
In the former option, we lose the main gain of this approach: explicit denotation of the aspect that can change. In the latter, it's just more ugly than it already is.
But functionally, I agree this is still static dispatch for statically known information, so that's fine by me.
How to test the change?
For now this is mostly demonstrative, not actually something that ought be merged.