## Motivation
There is currently no way to detect when a span is "empty" (i.e., it was
created with `Span::none`). This would be handy in cases where you want
to perform some (perhaps costly) additional metric-gathering when a
particular request _is_ being traced (i.e., it has a `Span`).
## Solution
This branch adds `Span::is_none`.
Closes#469
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Can't create a filter for a specific level without having to `match` on
a `Level`.
## Solution
Add `LevelFilter::from_level` `const` function and `From<Level> for
LevelFilter` impl
## Motivation
Makes it possible to get a `Level` without having to check which
`LevelFilter` is being used.
## Solution
Simply moves the inner `Option<Level>` out of the `LevelFilter`.
Added:
- `LookupSpans` implementation for `Layered` (#448)
- `SpanRef::from_root` to iterate over a span's parents from the root
(#460)
- `Context::scope`, to iterate over the current context from the root
(#460)
- `Context::lookup_current`, which returns a `SpanRef` to the current
span's data (#460)
Changed:
- Lifetimes on some new `Context` methods to be less restrictive (#460)
Fixed:
- `Layer::downcast_ref` returning invalid references (#454)
- Compilation failure on 32-bit platforms (#462)
- Compilation failure with ANSI formatters (#438)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
PR #443 added a `Context::scope` function, as described in issue #427.
In the issue, the desired change was described as follows:
> - The method `FmtContext::visit_spans` should be moved to
> `layer::Context`.
> - The new `layer::Context::visit_spans` should be renamed to
> something along the lines of `parents()`, **and be made to return
> a newtype implementing `std::iter::Iterator`.**
(emphasis mine)
Unfortunately, #443 only implemented the first bullet point — the new
`layer::Context::scope` method was just a copy of the old
`visit_spans`. The branch was merged before a thorough review could
determine that the change made there was incomplete.
## Solution
This branch changes the `Context::scope` function to return an
iterator, as it was supposed to, and rewrites `visit_spans` to consume
that iterator.
Additionally, I've added some new toys:
- `SpanRef::from_root`, which returns an iterator over a span's
parents, starting from the root (rather than from the direct parent
like `SpanRef::parents`)
- `Context::lookup_current`, which returns a `SpanRef` to the current
span's data
- Easier to use lifetimes on a couple of the new `Context` methods
enabled by the "registry" feature (not a breaking change, as these
aren't yet released)
Co-authored-by: David Barsky <me@davidbarsky.com>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
PR #441 increased the minimum supported Rust version, but it only
changed the Azure Pipelines CI configuration, and not the GitHub Actions
one. Additionally, upstream changes to `tower` has broken some of the
examples.
## Solution
This branch bumps the MSRV on GitHub Actions as well, and comments
out examples that depend on code broken upstream.
Additionally, it turns out that — due to Cool Cargo Semver Reasons —
it's more or less impossible to depend on both tokio 0.2.0-alpha.6 *and*
tokio 0.2 release versions. This branch therefore just drops the 0.2.0-alpha.6
support; the next `tracing-futures` will be a breaking change anyway.
Co-authored-by: David Barsky <me@davidbarsky.com>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Currently tracing-subscriber doesn't compile on 32-bit platforms as
discussed here: https://github.com/hawkw/sharded-slab/issues/9
The underlying issue has been fixed by @hawkw. This pull simply updates
the dependency inside this project. Thanks for your work on this!
## Motivation
Latest master cannot infer types in the `fmt` function.
## Solution
Tell the compiler the result type. Funnily I couldn't reproduce this
directly from `tracing` repo, but when I have `tracing` as a dependency
following it from github, the later versions would not pass `cargo
check`
We used to be on this version
`16fee661ac1f5dd175491e611ff4c08b33c070fa`, and `cargo update` would
break the project.
* futures: futures-03 & std-future is the default
Also upgrades futures-03 to the non-preview crate and
renames the `futures` feature to `futures-01`.
Fixes#418
* Update tracing-futures/CHANGELOG.md
Co-Authored-By: Eliza Weisman <eliza@buoyant.io>
* futures: Remove tokio feature from defaults
## Motivation
Currently, `Layer::downcast_raw` constructs a pointer with:
```rust
&self as *const _ as *const ()
```
This is wrong. The method's receiver is already `&self`, so this code
constructs a reference _to_ the `&self` reference, and converts _that_
into a pointer. Since this is not the actual memory address of the
layer, this is invalid.
We didn't catch this because the tests for downcasting layers are
also wrong: they never actually dereference the ref created by
`downcast_ref`. Therefore, if an invalid pointer is returned, the
test can still pass, as long as _any_ pointer is returned.
## Solution
This branch changes the pointer to:
```rust
self as *const _ as *const ()
```
Now, the returned pointer is valid.
In addition, it changes the tests to try and access data through the
returned references. The new tests fail with the current master
implementation of `downcast_ref`, which is correct.
Fixes#453
Currently there are some links that 404 because they contain
a reference to a struct 'struct.Layer.html' which presumably
should be the trait 'layer/trait.Layer.html'.
Signed-off-by: ifeanyi <ify1992@yahoo.com>
## Motivation
What I wanted to achieve: lookup data from a span _outside_ of a
`Layer`/`Subscriber` implementation. (i.e. without having a
`Context<S>`)
What I was trying: get the configured subscriber with
`dispatcher::get_default(...)`, and then downcasting to a `Layered<....,
Registry>`. But I (a) cant get access to the inner `Registry` and (b)
don't have an implementation of `LookupSpan` for `Layered`.
## Solution
Since there was already a `LookupMetadata` impl, this just seemed like
an oversight. So I changed the implementation over.
Note that `LookupMetadata` gets implemented via the blanket impl on
`L: LookupSpan`.
This patch moves the current `FmtContext::visit_spans`
implementation into a new method `layer::Context::scope`, leaving
`visit_spans` itself in place in order to maintain compatibility.
Resolves#427
Signed-off-by: ifeanyi <ify1992@yahoo.com>
## Motivation
This branch fixes several bugs in the `Registry` span close logic, and
adds new tests for these issues.
## Solutions
* Spans not being removed at the end of `on_close`
There is currently a bug in the `Registry` that prevents spans from
being removed, even when all `on_close` callbacks are complete. The test
for this behavior ( `span_is_removed_from_registry`) fails to catch the
bug, since there is a bug in the test as well.
The test asserts that a span extension was dropped after the span
closes. Current, the test uses `subscriber::with_default`, and then
made the assertion _outside_ of the `with_default` block. However, this
was incorrect, as even if the `Registry` fails to drop the span, the
span extension will be dropped when the whole `Registry` itself is
dropped, at the end of the `with_default` block.
This branch fixes the test, and the bug in the close logic. I've changed
the test to use an explicit `Dispatch` to keep the registry alive until
the end of the test. This reveals that the span is _not_ being removed
as it should be.
The reason the span fails to be removed is that the `Drop`
implementation for `CloseGuard` drops the span if the value of the
`CLOSE_COUNT` cell is 0. However, the `if` statement that tests for this
compares the value returned by `Cell::get` with 0. The value returned by
`Cell::get` is the _previous_ value, not the current one after dropping
this guard; if the guard being dropped is the final guard, then the
value returned by `Cell::get` will be 1, rather than 0.
I've fixed this logic, and refactored it slightly to hopefully make it
easier to understand in the future.
Thanks to @jtescher for catching this bug!
* Only the first span being removed at the end of `on_close`
In addition, I've fixed a bug where the remove after close logic would
only work for the _first_ span to close on each thread. This is because
dropping a `CloseGuard` does not currently subtract from CLOSE_COUNT
when it is the final guard. This means that when the next span is
closed, the count will start at 1, rather than 0. I've fixed this by
ensuring that the close count is always decremented, and changed the
tests to close multiple spans.
* Spans removed on the first `try_close`
Finally, there is also an issue where the removal logic is run on
_every_ call to `try_close`, regardless of whether or not the subscriber
actually indicates that the span closes. This means that a span will be
removed from the registry even when there are one or more span handles
that reference it.
This is due to the `start_close` method being called _before_
`Subscriber::try_close` is called. When a close guard is dropped, the
span is currently _always_ removed. However, since we call `start_close`
at the beginning of the `Layered::try_close` method, we may be
decrementing a ref count _without_ closing the span, but the close guard
is unaware of this.
I've fixed this bug by updating the `CloseGuard` struct to track whether
the span is closed. It now has a bool that is set only when the
`Subscriber::try_close` call returns true.
Only creating the `CloseGuard` if `try_close` returns true may seem like
a simpler solution, but that won't work, since the call to `try_close`
may call into another `Layered` subscriber. In order to handle
situations where many layers are nested, we need to construct the
`CloseGuard` for each stack frame before calling into the next one, so
it's necessary to set whether the span is closing only after the call to
`try_close` returns.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This PR removes the deprecated items, notices and aliases in preparation
of releasing tracing-subscriber 0.2.0-alpha.1.
Signed-off-by: David Barsky me@davidbarsky.com
For Registry-backed Layers, this commit introduces a capability where
span deletion is deferred until until all Layers have processed the span
closure notification.
`fmt::Layer::on_record` was looking up extensions using
`FormattedFields<Self>>` when it should have been using
`FormattedFields<N>>`.
Signed-off-by: David Barsky me@davidbarsky.com
Following the suggested fix on #365:
https://github.com/tokio-rs/tracing/issues/365#issuecomment-537743811
tracing-core's use of `spin` is feature-gated. `lazy_static` is vendored
for either feature but I've modified it to respect our feature flags.
I've also removed doc comments that no longer compile and suppressed a
couple of warnings with the lints that are now being applied.
At this point
* Including this in another project with std `lazy_static`
works
* Tracing unit tests pass both with and without
`--no-default-features`
Fixes#365
* core: vendor lazy_static and spin for no_std support
* core: fmt vendored code
* core: trim down vendored spin, reduce visibility and addresss warnings
* core: limit vendored lazy_static for use only with no_std, fix warnings
* core: update paths to now-vendored no_std libs
* tracing: use spin::Once re-exported from tracing-core instead of crate
* core: remove ineffectual doc(hidden)
* core: refmt stdlib module
* core: bump to 0.1.8 to expose export of vendored spin::Once to tracing
With #420, we introduced FmtContext and made it a required parameter on
FormatEvent's primary methods. However, we forgot to export it, making
it impossible to write custom FormatEvent implementations. This PR fixes
that oversight. Thanks to @samscott89 for noticing this!
Signed-off-by: David Barsky me@davidbarsky.com
This branch introduces:
- A registry build atop of https://github.com/hawkw/sharded-slab. Layers
are expected to consume this registry through the traits `SpanData`,
`LookupSpan`, and `LookupMetadata`. Layer-specific data, such as
formatted spans and events, are stored in the `Extensions` typemap. Data
is writable via the `ExtensionsMut` view struct of the typemap. This
enables layers to read and write data that they are specifically
interested in.
- The `tracing_subscriber::fmt::Subscriber` has been re-implemented in
terms of `tracing_subscriber::registry::Registry` and
`tracing_subscriber::fmt::Layer`.
- The event/field formatters have been modified (in a non-backwards
compatible way) to accept a `tracing_subscriber::fmt::FmtContext`. A
similar structure existed in `tracing_subscriber::fmt::Subscriber`, but
it was not publicly exposed.
Resolves#135Resolves#157Resolves#391
Signed-off-by: David Barsky <me@davidbarsky.com>
Coauthored-by: Eliza Weisman <eliza@buoyant.io>
These benchmarks were originally written for assessing before/after
performance on a branch that was not merged. However, they are probably
generally useful for other fmt subscriber changes (e.g. #420).
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
The futures-preview code will remain in place to avoid breaking existing
code; the new futures 0.3 support has a separate feature flag.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
A recent upstream change to `tokio-test` (tokio-rs/tokio#1728) removed
the `MockTask` API in favour of a more ergonomic `task::spawn` API. This
broke our tests for `tracing-futures` and `tracing-attributes` `std::future`
compatibility, which depend on `tokio-test` from Git.
## Solution
This branch updates these tests to use the new API, which *is* much
nicer. This should fix nightly CI.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
As outlined in #172, we can improve the use of default dispatch by
implementing `Default` to create `Dispatch::default`, thus making
the default dispatcher easier to use.
## Solution
This PR adds an implementation of `Default` trait from the standard
library that calls `get_default` and returns a clone of the default
dispatcher.
Closes#172
Signed-off-by: Adityo Pratomo <adityo@tetrate.io>
### Added
- `Instrumented::inner` and `inner_mut` methods that expose access to the
instrumented future (#386)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* log: deprecate `TraceLogger`
This deprecation was discussed in
https://github.com/tokio-rs/tracing/issues/369#issuecomment-541853727.
This API should not be used, as the `tracing` crate's `log` and
`log-always` features provide better implementations of the same
functionality, and the implementation here contains some deadlocks that
make it unusable in real-world use-cases.
Closes#369
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* log: minor readme tweaks
- Improve list of provded APIs
- Remove Gitter
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* log: prepare to release 0.1.1
### Deprecated
- `TraceLogger` (use `tracing`'s "log" and "log-always" feature flags instead)
### Fixed
- Issues with `log/std` feature flag (#406)
- Minor documentation issues (#405, #408)
* fix deprecation warning on reexport
* rustfmt
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
I thought the boxing errors solution implemented in #400 was equivalent
to the enum solution in
f22bae5a2d,
but the current master doesn't actually work to install the global
`LogTracer`.
I can't figure out why the current cargo features don't end up turning
on [this line][1], but I confirmed with the log example in
4511325b29
that it's not currently working.
[1]: https://github.com/tokio-rs/tracing/blob/master/tracing-subscriber/src/fmt/mod.rs#L452-L453
* subscriber: use InitError enum instead of Box
the Boxing solution while using the feature tracing-log/std didn't actually seem to work
* examples: log compatibility
* fix dependencies
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* fix boxed errors
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* cargo fmt
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, most crates in `tracing` are configured to deny all compiler
warnings when compiling tests. This means that if the compiler reports
any warnings, the build will fail. This can be an issue when changes are
made locally that introduce warnings (i.e. unused code is added, imports
are no longer needed, etc) and a contributor wishes to test an
incomplete state to ensure their changes are on the right path. With
warnings denied, tests will not run if the project contains any
warnings, so contributors must either fix all warnings or disable the
deny attribute. Disabling the deny attribute when making changes locally
has become a fairly common practice, but it's error-prone: sometimes,
the deny attribute is commented out and then accidentally committed.
## Solution
This branch removes all `#![deny(warnings)]` attributes, in order to
allow code with warnings to compile and be tested locally while changes
are in progress. We already have [a CI job][1] that checks for compiler
warnings by trying to compile `tracing` with `RUSTFLAGS="-Dwarnings"`.
If we make this CI job required rather than allowing it to fail, we'll
still be able to ensure that no code with warnings is merged.
Additionally, I've updated all crates to use the same consistent list of
lints to apply in the `#![warn]` attribute. Previously, some crates
warned on more lints than others, which is not great. I've fixed all the
new warnings produced by the additional lints.
* chore: consistent warnings, don't deny locally
* fix warnings from new attributes
* remove warning that no longer exists on nightly
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Setting `RUST_LOG=target` currently enables only the `ERROR` level,
while it should enable everything.
## Solution
Change the default to `TRACE` if no level is specified
* tracing: bump attrs and core versions
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* tracing: prepare to release 0.1.10
Added
- Support for destructuring in arguments to `#[instrument]`ed functions
(#397)
- Generated field for `self` parameters when `#[instrument]`ing methods
(#397)
- Optional `skip` argument to `#[instrument]` for excluding function
parametersfrom generated spans (#359)
- Added `dispatcher::set_default` and `subscriber::set_default` APIs,
which return a drop guard (#388)
Fixed
- Some minor documentation errors (#356, #370)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
https://github.com/tokio-rs/tracing/pull/385 incorrectly used the
feature flag `tracing_log` when it should have been `tracing-log`. As a
result, you need to specify both in order to make `try_init` initialize
the global logger.
## Solution
Use the correct feature flag
Added:
- Support for destructuring in arguments to `#[instrument]`ed
functions (#397)
- Generated field for `self` parameters when `#[instrument]`ing
methods (#397)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This pull request adds support to the `#[instrument]` macro for
destructured arguments.
## Motivation
The `#[instrument]` macro automatically adds function arguments as
fields on the `Span`. Previously, it would only do so for "plain"
`Ident` argument types, but would ignore destructured arguments.
## Solution
By recursively pattern matching each argument to find all identifiers it
creates, we can construct an authoritative list of all input names.
* attributes: extract param_names extractor
To enable the recursion needed to extract all the various
destructured parameter types.
* attributes: support destructured tuple arguments
* attributes: support destructured ref arguments
* attributes: support destructured tuple struct arguments
* attributes: support destructured struct arguments
* attributes: add crazy destructuring test
This is to test the combination of all the supported function
argument destructuring types.
* attributes: move destructuring tests to their own file
* attributes: apply cargo fmt
* attributes: add helpful comment to pattern pattern match
Since function signatures can only use irrefutable patterns,
we can be confident that no legal code will have any other
variant of `syn::Pat` than the ones we match on. However, to
prevent anyone else from going down the rabbit hole of
wondering about it, we add a helpful comment.
* attributes: support self argument as span field
### Added
- Added `dispatcher::set_default` API which returns a drop guard (#388)
### Fixed
- Added missing `Value` impl for `u8` (#392)
- Broken links in docs.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
