backport recent changes from master #2324
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
The error messages for these tests appear to have changed a bit with Rust 1.64. This commit includes changes to the `.stderr` file after running the tests with `TRYBUILD=overwrite`, in order to update the expected output for the latest Rust.
The `async_fn` test file in `tracing-attributes` contains several functions that exist just to test whether they _compile_, rather than make assertions about their behavior. Because these functions are never called, they (naturally) emit dead code warnings. This commit adds `#[allow(dead_code)]` to the compilation tests, plus a comment explaining why we do this.
hawkw
force-pushed
the
eliza/backport-2323
branch
from
341d88f to
7d5c10a
Compare
|
@guswynn I can take care of it, thanks! |
Allows `Subscriber`s and `Layer`s to stash their own `Dispatch` without causing a memory leak. ## Motivation Resolves a shortcoming of #2269: that it's impossible for `Subscriber`s or `Layer`s to stash a copy of their own `Dispatch` without creating a reference cycle that would prevent them from being dropped. ## Solution Introduces `WeakDispatch` (analogous to `std::sync::Weak`) that holds a weak pointer to a `Subscriber`. `WeakDispatch` can be created via `Dispatch::downgrade`, and can be transformed into a `Dispatch` via `WeakDispatch::upgrade`. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation `tracing-appender` does not have `Rotation` based on size yet. Also, it doesn't have the feature of keeping the most recent `N` log files I believe the second feature is more easy to implement, and also will partially solve the `Rotation` based on size problem. Because people may choose `hourly` or `daily` rotation based on their needs, and put an extra boundary of `keep the last 5 files` for example. Of course it won't handle all the edge cases for `Rotation` based on size. But it will cover most of the scenarios. And also, it is a good feature to have on its own :) ## Solution Introduce another field called `max_files: Option<usize>` to the `Inner` of `RollingFileAppender` struct. I managed to did not touch any of the existing functions, so it **WON'T BE A BREAKING CHANGE**. Yay :) The solution is, whenever the rotation should happen, the `refresh_writer()` is called. So I embed the following logic into that function: 1- check the log folder and detect the log files 2- if there are more log files than the `max_files` amount 3- store the filenames in a vector, and sort them by their dates (dates are already present in the filename) 4- keep deleting the oldest ones, till we have desired amount of log files in the log folder P.S. this PR was opened before, but got closed since it would be easier for the maintainers to target `master` branch instead of `v0.1.x` Also, @CBenoit contributed to this PR, it would be great to give credit to him :) Co-authored-by: Benoît Cortier <bcortier@proton.me> Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation Currently, when using the `Layer` impl for `Option<S: Layer<...>>`, the `Layer::max_level_hint` returns `Some(LevelFilter::OFF)`. This was intended to allow totally disabling output in the case where a `Subscriber` is composed entirely of `None` `Layer`s. However, when other `Layer`s *do* exist but return `None` from their `max_level_hint` implementations to indicate that they don't care what the max level is, the presence of a single `None` layer will globally disable everything, which is not the wanted behavior. Fixes #2265 ## Solution This branch introduces a special downcast marker that can be used to detect when a `Layer` in a `Layered` is `None`. This allows the `pick_level_hint` method to short-circuit when a `Layer` implementation which is `None` returns `Some(LevelFilter::OFF)` from its `max_level_hint` if the other half of the `Layered` is not `None`. The tests I added should be pretty thorough! Additionally, the downcast marker is special-cased in the `reload` `Layer`. Normally, this `Layer` doesn't support downcasting, but it can in the case of the special marker value. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
#2326) ## Motivation This fixes a discrepancy in the `tracing-opentelemetry` docs for the new MetricsLayer. The docs refer to `value.` as a way to collect discrete data point, but this doesn't match any of the prefix constant mentioned in the same file. ```rust const METRIC_PREFIX_MONOTONIC_COUNTER: &str = "monotonic_counter."; const METRIC_PREFIX_COUNTER: &str = "counter."; const METRIC_PREFIX_HISTOGRAM: &str = "histogram."; ``` ## Solution This fixes the documentation and test by referring to `histogram.` instead of `value.`.
hawkw
force-pushed
the
eliza/backport-2323
branch
from
7d5c10a to
257f86f
Compare
jtescher
approved these changes
Sep 30, 2022
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 PRs from
master:Dispatch::downgrade()andWeakDispatch(tracing-core: AddDispatch::downgrade()andWeakDispatch#2293)