backport commits from master to v0.1.x
#2233
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
## Motivation When using a `reload` layer, the fast-path current level check doesn't work, as the `max_level_hint` is just `None`, which `rebuild_interest` interprets as `TRACE` ## Solution Pass through to the underlying layer/filter. On poisons, when already panicking, just return `None`
Older versions use node 12 which is no longer supported (end-of-life on April 30, 2022). Also, @main/@master is not very good as they may run into unreleased breaking changes.
Motivation: When a user clicks they they may accidentally get an old version of the crate. Its also out of sync with the current main readme. Solution: removed the hard coded links
## Motivation I find it useful when debugging applications with lots of threads to easily identity them by their names. ## Solution Just name the thread as other crates such as `sentry-rust` are doing. Co-authored-by: Guillaume Desmottes <[email protected]>
Previously, using `record("x", "y")` would give an error:
```
error[E0277]: the size for values of type `str` cannot be known at compilation time
--> src/main.rs:3:22
|
243 | span.record("x", "y");
| ^^^^^^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `str`
note: required by a bound in `Span::record`
--> /home/jnelson/.local/lib/cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/tracing-0.1.32/src/span.rs:1184:30
|
1184 | pub fn record<Q: ?Sized, V>(&self, field: &Q, value: &V) -> &Self
| ^ required by this bound in `Span::record`
```
Now it works fine, as tested by the doc-example.
This doesn't break any existing code, because there's a generic `impl<T: Value> Value for &T`: https://docs.rs/tracing/0.1.35/tracing/trait.Value.html#impl-Value-for-%26%27a%20T
Co-authored-by: Eliza Weisman <[email protected]>
There's no automated propagation of subscribers between spans, you have to do this manually. https://discord.com/channels/500028886025895936/997201342596657232/997210656677830778 Co-authored-by: Eliza Weisman <[email protected]>
## Motivation Several currently open PRs, such as #2225 and #2221, add new configuration parameters to the rolling file appender in `tracing-appender`. The best way to add new optional configuration settings without breaking existing APIs or creating a very large number of new constructors is to add a builder interface. ## Solution Since a number of PRs would all need to add the builder API, introducing potential conflicts, this branch _just_ adds the builder interface without adding any new configuration options. Once this merges, the existing in-flight PRs can be rebased onto this branch to use the builder interface without conflicting with each other. Also, the `Builder::build` method is fallible and returns a `Result`, rather than panicking. This is a relatively common pattern in Rust --- for example, `std::thread::Builder::spawn` returns a `Result` if a new thread cannot be spawned, while `std::thread::spawn` simply panics. This allows users to handle appender initialization errors gracefully without breaking the API of the existing `new` constructor. Fixes #1953 Signed-off-by: Eliza Weisman <[email protected]>
A `FieldSet` is equal to another `FieldSet` if they share the same callsite and fields (provided in the same order). This ensures that a `Field` applicable to one `FieldSet` is applicable to any equal `FieldSet`. A `Metadata` is equal to another `Metadata` if all of their contained metadata is exactly equal. This change manually re-implements `PartialEq` and `Eq` for `Metadata` and `FieldSet` to define their equality strictly in terms of callsite equality. In debug builds, the equality of these types' other fields is also checked. Documentation is added to both `Metadata` and `FieldSet` explaining this behavior. The expectation that, in a well-behaving application, `Metadata` and `FieldSet`s with equal callsites will be otherwise equal is documented on `Callsite::metadata`. This is not a breaking change, as previous releases did not define equality for `Metadata` or `FieldSet`. The `Callsite` trait remains safe, as this expectation is not (yet) a safety-critical property.
hawkw
force-pushed
the
eliza/backport-2204
branch
from
cf3ab0e
to
f4da668
Compare
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.
This backports the following commits from
mastertov0.1.x:PartialEq,EqforMetadata,FieldSet(tracing-core: implementPartialEq,EqforMetadata,FieldSet#2229)RollingFileAppenders (appender: add a builder for constructingRollingFileAppenders #2227)Span::record(Allow owned values and fat pointers inSpan::record#2212)max_level_hintinreload(pass through max_level_hint in reload::Layer #2204)