-
Notifications
You must be signed in to change notification settings - Fork 720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
subscriber: make FmtSubscriber
's auto traits not depend on C
#2024
Merged
Conversation
This file contains 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
this moves the "runtime configuration with subscribers" section into a subsection of "composing subscribers". Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation Currently, `FmtSubscriber` holds a `PhantomData<C>` with the `Collect` type it wraps. This is unfortunate because it means that the subscriber's auto traits such as `Send`, `Sync`, and `'static` (as well as `UnwindSafe`, `Unpin`, etc) depend on the collector type's auto traits...but the subscriber will never actually _store_ a value of type `C`. While all collectors will be `Send + Sync + 'static` in practice, the `PhantomData` means that functions returning a boxed `FmtSubscriber` must unnecessarily bound the collector type parameter. ## Solution This commit changes the `PhantomData` to `PhantomData<fn(C)>`, solving the problem.
davidbarsky
approved these changes
Mar 25, 2022
hawkw
added a commit
that referenced
this pull request
Mar 29, 2022
Depends on #2023 ## Motivation Currently, `FmtLayer` holds a `PhantomData<S>` with the `Subscriber` type it wraps. This is unfortunate because it means that the layer's auto traits such as `Send`, `Sync`, and `'static` (as well as `UnwindSafe`, `Unpin`, etc) depend on the `Subscriber` type's auto traits...but the layer will never actually _store_ a value of type `S`. While all `Subscriber` will be `Send + Sync + 'static` in practice, the `PhantomData` means that functions returning a boxed `FmtLayer` must unnecessarily bound the subscriber type parameter. ## Solution This commit changes the `PhantomData` to `PhantomData<fn(S)>`, solving the problem. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw
added a commit
that referenced
this pull request
Mar 29, 2022
Depends on #2023 ## Motivation Currently, `FmtLayer` holds a `PhantomData<S>` with the `Subscriber` type it wraps. This is unfortunate because it means that the layer's auto traits such as `Send`, `Sync`, and `'static` (as well as `UnwindSafe`, `Unpin`, etc) depend on the `Subscriber` type's auto traits...but the layer will never actually _store_ a value of type `S`. While all `Subscriber` will be `Send + Sync + 'static` in practice, the `PhantomData` means that functions returning a boxed `FmtLayer` must unnecessarily bound the subscriber type parameter. ## Solution This commit changes the `PhantomData` to `PhantomData<fn(S)>`, solving the problem. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
kaffarell
pushed a commit
to kaffarell/tracing
that referenced
this pull request
May 22, 2024
) Depends on tokio-rs#2023 ## Motivation Currently, `FmtLayer` holds a `PhantomData<S>` with the `Subscriber` type it wraps. This is unfortunate because it means that the layer's auto traits such as `Send`, `Sync`, and `'static` (as well as `UnwindSafe`, `Unpin`, etc) depend on the `Subscriber` type's auto traits...but the layer will never actually _store_ a value of type `S`. While all `Subscriber` will be `Send + Sync + 'static` in practice, the `PhantomData` means that functions returning a boxed `FmtLayer` must unnecessarily bound the subscriber type parameter. ## Solution This commit changes the `PhantomData` to `PhantomData<fn(S)>`, solving the problem. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Depends on #2023
Motivation
Currently,
FmtSubscriber
holds aPhantomData<C>
with theCollect
type it wraps. This is unfortunate because it means that the
subscriber's auto traits such as
Send
,Sync
, and'static
(as wellas
UnwindSafe
,Unpin
, etc) depend on the collector type's autotraits...but the subscriber will never actually store a value of type
C
. While all collectors will beSend + Sync + 'static
in practice,the
PhantomData
means that functions returning a boxedFmtSubscriber
must unnecessarily bound the collector type parameter.
Solution
This commit changes the
PhantomData
toPhantomData<fn(C)>
, solvingthe problem.