-
Notifications
You must be signed in to change notification settings - Fork 721
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
Add accessor functions necessary for structured serde #2152
Conversation
tracing-core/src/span.rs
Outdated
/// when [`Record::record()`] is called | ||
/// | ||
/// [`Record::record()`]: Record::record() | ||
pub fn record_len(&self) -> usize { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would probably just call this len
, to be honest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
going to rename these to len
and go ahead and merge it!
Head branch was pushed to by a user without write access
# 0.1.27 (June 7, 2022) This release of `tracing-core` introduces a new `DefaultCallsite` type, which can be used by instrumentation crates rather than implementing their own callsite types. Using `DefaultCallsite` may offer reduced overhead from callsite registration. ### Added - `DefaultCallsite`, a pre-written `Callsite` implementation for use in instrumentation crates ([#2083]) - `ValueSet::len` and `Record::len` methods returning the number of fields in a `ValueSet` or `Record` ([#2152]) ### Changed - Replaced `lazy_static` dependency with `once_cell` ([#2147]) ### Documented - Added documentation to the `callsite` module ([#2088], [#2149]) Thanks to new contributors @jamesmunns and @james7132 for contributing to this release! [#2083]: #2083 [#2152]: #2152 [#2147]: #2147 [#2088]: #2088 [#2149]: #2149
# 0.1.27 (June 7, 2022) This release of `tracing-core` introduces a new `DefaultCallsite` type, which can be used by instrumentation crates rather than implementing their own callsite types. Using `DefaultCallsite` may offer reduced overhead from callsite registration. ### Added - `DefaultCallsite`, a pre-written `Callsite` implementation for use in instrumentation crates ([#2083]) - `ValueSet::len` and `Record::len` methods returning the number of fields in a `ValueSet` or `Record` ([#2152]) ### Changed - Replaced `lazy_static` dependency with `once_cell` ([#2147]) ### Documented - Added documentation to the `callsite` module ([#2088], [#2149]) Thanks to new contributors @jamesmunns and @james7132 for contributing to this release! [#2083]: #2083 [#2152]: #2152 [#2147]: #2147 [#2088]: #2088 [#2149]: #2149
## Motivation This PR adds two new accessor functions that are useful for creating a structured serde implementation for tracing. This is a sort of "distilled" version of #2113, based on the `v0.1.x` branch. As it is unlikely that "structured serde" will be 1:1 compatible with the existing JSON-based `tracing-serde` (or at least - I'm not sure how to do it in a reasonable amount of effort), these functions will allow me to make a separate crate to hold me over until breaking formatting changes are possible in `tracing-serde`. CC @hawkw, as we've discussed this pretty extensively
This PR adds two new accessor functions that are useful for creating a structured serde implementation for tracing. This is a sort of "distilled" version of #2113, based on the `v0.1.x` branch. As it is unlikely that "structured serde" will be 1:1 compatible with the existing JSON-based `tracing-serde` (or at least - I'm not sure how to do it in a reasonable amount of effort), these functions will allow me to make a separate crate to hold me over until breaking formatting changes are possible in `tracing-serde`. CC @hawkw, as we've discussed this pretty extensively
This PR adds two new accessor functions that are useful for creating a structured serde implementation for tracing. This is a sort of "distilled" version of #2113, based on the `v0.1.x` branch. As it is unlikely that "structured serde" will be 1:1 compatible with the existing JSON-based `tracing-serde` (or at least - I'm not sure how to do it in a reasonable amount of effort), these functions will allow me to make a separate crate to hold me over until breaking formatting changes are possible in `tracing-serde`. CC @hawkw, as we've discussed this pretty extensively
This PR adds two new accessor functions that are useful for creating a structured serde implementation for tracing. This is a sort of "distilled" version of #2113, based on the `v0.1.x` branch. As it is unlikely that "structured serde" will be 1:1 compatible with the existing JSON-based `tracing-serde` (or at least - I'm not sure how to do it in a reasonable amount of effort), these functions will allow me to make a separate crate to hold me over until breaking formatting changes are possible in `tracing-serde`. CC @hawkw, as we've discussed this pretty extensively
# 0.1.27 (June 7, 2022) This release of `tracing-core` introduces a new `DefaultCallsite` type, which can be used by instrumentation crates rather than implementing their own callsite types. Using `DefaultCallsite` may offer reduced overhead from callsite registration. ### Added - `DefaultCallsite`, a pre-written `Callsite` implementation for use in instrumentation crates ([tokio-rs#2083]) - `ValueSet::len` and `Record::len` methods returning the number of fields in a `ValueSet` or `Record` ([tokio-rs#2152]) ### Changed - Replaced `lazy_static` dependency with `once_cell` ([tokio-rs#2147]) ### Documented - Added documentation to the `callsite` module ([tokio-rs#2088], [tokio-rs#2149]) Thanks to new contributors @jamesmunns and @james7132 for contributing to this release! [tokio-rs#2083]: tokio-rs#2083 [tokio-rs#2152]: tokio-rs#2152 [tokio-rs#2147]: tokio-rs#2147 [tokio-rs#2088]: tokio-rs#2088 [tokio-rs#2149]: tokio-rs#2149
Motivation
This PR adds two new accessor functions that are useful for creating a structured serde implementation for tracing.
This is a sort of "distilled" version of #2113, based on the
v0.1.x
branch.As it is unlikely that "structured serde" will be 1:1 compatible with the existing JSON-based
tracing-serde
(or at least - I'm not sure how to do it in a reasonable amount of effort), these functions will allow me to make a separate crate to hold me over until breaking formatting changes are possible intracing-serde
.CC @hawkw, as we've discussed this pretty extensively