## Motivation
As discussed in #308, there are a large number of crates in this
repository, which can be confusing for users and can increase the
maintainance burden for maintainers. Also, the `tracing-fmt` and
`tracing-subscriber` crates both contain filtering implementations with
similar behaviour and APIs, but `tracing-subscriber`'s filter module
offers more advanced features (filtering on field values), and is usable
with any subscriber implementation. Two separate filter implementations
also has the potential to be confusing for users.
## Solution
This branch moves most of the code from `tracing-fmt` into a module in
`tracing-subscriber`, and changes the `tracing-fmt` builder APIs to use
the `Filter` type in `tracing-subscriber`. The `tracing-subscriber/fmt`
feature flag can be used to disable the formatting subscriber when it is
not used.
The `tracing-fmt` crate has been updated to re-export the APIs from
`tracing-subscriber`, and marked as deprecated. Once we've published a
new version of `tracing-subscriber` with the format APIs, we can publish
a final release of `tracing-fmt` that will update the documentation &
mark all APIs as deprecated, so that users know to move to the
`tracing-subscriber` crate.
Refs: #308
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
`tracing` is built with Rust's 2018 edition, but some examples use
outdated idioms. Ideally, examples would show code using the currently
preferred idioms. This improves clarity, especially for newer Rust
programmers who may not be familiar with the idioms of earlier editions.
## Solution
This branch updates all the examples to use Rust 2018 edition idioms,
and adds `deny` attributes to prevent the use of outdated idioms.
* deny rust 2018 idiom lints in examples
* examples: update to use Rust 2018 idioms
* examples: remove most uses of `extern crate`
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
In order to re-export the `#[instrument]` attribute macro in `tracing`,
it must be released to crates.io. There are some changes that needed to
be made prior to releasing the procedural macro crate.
## Solution
This branch makes the following changes:
- Rename the attribute macro from `trace` to `instrument` (see #246)
- Add support for setting a verbosity level (see #250)
- Add support for setting a target
- Rename the `tracing-proc-macros` crate to `tracing-attributes`
- Add documentation + a README
- Update Cargo.toml metadata
The crate should now be ready to publish and re-export from `tracing`.
Fixes: #246Fixes: #250
Refs: #245
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The `tracing-proc-macros` crate provides an attribute macro that
instruments a function. When an instrumented function is called, a span
with the function's name and parameters is created and entered for the
duration of the call. However, this does not currently handle
`async fn`s properly --- the correct behaviour would be to instrument
the _future_ created by the async function.
## Solution
This branch updates the attribute macro to properly handle async
functions. This is done by expanding the function body inside of an
async block, using the `tracing-futures::Instrument` combinator on that
block, and `await`ing the instrumented block. This should function
equivalently to the un-instrumented function, but with the addition that
the `Instrumented` combinator future will ensure that the generated span
is entered every time the async block's future is polled.
Since we build and test `tracing` on stable Rust, a `nightly` feature
flag is required to enable support for `async fn`s. If the attribute is
added to an async fn without that feature enabled, we will generate a
compiler error that indicates that this feature should be enabled.
I've also added examples and tests for instrumenting `async fn`s. These
are in their own separate workspaces so that they do not break
`cargo test --all` on stable.
Closes#6Fixes#162
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
