## Motivation

The `tracing-macros` crate doesn't currently compile with the latest
`tracing` release, because it uses internal private API that changed.
We need to fix this so CI isn't broken.

## Solution

I changed the `dbg!` macro so it no longer uses internal APIs. Ideally,
we would implement `dbg!` using the support for string-literal field
names that was recently added to `tracing`, but I couldn't actually get
it to work --- I think the `event!` macros may not handle string literal
field names properly (we only test them with the `span!` macros >_>).
Will try to fix that later, but for now, this fixes CI and I don't think
anyone actually uses the experimental, unreleased `tracing-macros` 
crate.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

Backports tokio-rs#1012 to v0.1.x.

This adds support for having dashes in log target names, like:
`target-name=info`

## Motivation

We are using log targets with dashes in our project.

## Solution

Extend the target parsing regex to support dashes.

…u64) (tokio-rs#1007) (tokio-rs#1013)

This backports tokio-rs#1007 to v0.1.x.

## Motivation

While using `tracing-opentelemetry` I noticed all the data gets sent to the
collector as a string. This implements the additional data types and (possibly)
saves bandwidth.

## Solution

I just implemented additional `fn record_$type(...)` methods of the
`field::Visit` trait to `SpanEventVisitor` and `SpanAttributeVisitor`.

(cherry picked from commit 04bbb15)

…io-rs#1021)

## Motivation

Fixes tokio-rs#975.

## Solution

This implements the warning in `tracing-subscriber` only, as mentioned
in
tokio-rs#975 (comment).
It warns whenever directives are parsed, including programmatically and
through environment variables. It does not include the suggested new API
which returns the filters that wouldn't be parsed.

- List filters that would be ignored
- Mention 'static max level'
- Describe how to enable the logging

Example output:

```
$ RUST_LOG=off,debug,silenced[x]=trace cargo run -q
warning: some trace filter directives would enable traces that are disabled statically
 | `debug` would enable the DEBUG level for all targets
 | `silenced[x]=trace` would enable the TRACE level for the `silenced` target
 = note: the static max level is info
 = note: to enable DEBUG logging, remove the `max_level_info` feature
```
![image](https://user-images.githubusercontent.com/23638587/95243324-77dc6a00-07de-11eb-8ed3-6ee2109940d4.png)

This backports PR tokio-rs#991 to v0.1.x. This is primarily necessary for the MSRV
bump, since some dependencies no longer compile on Rust 1.40.0.

This has already been approved on `master`, in PR tokio-rs#991, so it should be 
fine to ship.

## Motivation

This will avoid breaking CI on new releases of clippy. It also makes the
code a little easier to read.

## Solution

- Convert `match val { pat => true, _ => false }` to `matches!(val, pat)`
- Remove unnecessary closures
- Convert `self: &mut Self` to `&mut self`

This bumps the MSRV to 1.42.0 for `matches!`.
The latest version of rust is 1.46.0, so as per
https://github.com/tokio-rs/tracing#supported-rust-versions this is not
considered a breaking change.

I didn't fix the following warning because the fix was not trivial/needed
a decision:

```
warning: you are deriving `Ord` but have implemented `PartialOrd` explicitly
   --> tracing-subscriber/src/filter/env/field.rs:16:32
    |
16  | #[derive(Debug, Eq, PartialEq, Ord)]
    |                                ^^^
    |
    = note: `#[warn(clippy::derive_ord_xor_partial_ord)]` on by default
note: `PartialOrd` implemented here
   --> tracing-subscriber/src/filter/env/field.rs:98:1
    |
98  | / impl PartialOrd for Match {
99  | |     fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
100 | |         // Ordering for `Match` directives is based first on _whether_ a value
101 | |         // is matched or not. This is semantically meaningful --- we would
...   |
121 | |     }
122 | | }
    | |_^
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord
```

As a side note, this found a bug in clippy 😆 rust-lang/rust-clippy#6089

### Changed

- Updated `tracing-core` to 0.1.17 ([tokio-rs#992])

### Added

- **env-filter**: Added support for filtering on targets which contain
  dashes ([tokio-rs#1014])
- **env-filter**: Added a warning when creating an `EnvFilter` that
  contains directives that would enable a level disabled by the
  `tracing` crate's `static_max_level` features ([tokio-rs#1021])

Thanks to @jyn514 and @bkchr for contributing to this release!

[tokio-rs#992]: tokio-rs#992
[tokio-rs#1014]: tokio-rs#1014
[tokio-rs#1021]: tokio-rs#1021

## Motivation

It is currently possible to create a span graph which includes a span
that has both an invalid parent otel context _and_ a missing trace id by
assigning an invalid extracted parent context to a non-root span.
Constructing this particular graph will currently cause a panic.

## Solution

Explicitly assign invalid trace / span ids when sampling using the otel
SDK if the span builder does not contain these values.

…kio-rs#1037)

…kio-rs#1059)

This backports tokio-rs#1058 to v0.1.x. This was already approved on master.

## Motivation

We've tried very hard to make sure that entering and exiting spans is
lightweight...in the `tracing-core` core machinery. Unfortunately, we
haven't done any benchmarking of how subscriber implementations actually
handle enter/exit events. It turns out that in `tracing-subscriber`'s
`Registry`, there's actually significant overhead for entering a span:
calling `span.enter()` may take as long as 69 ns (on my machine).

## Solution

I've written some microbenchmarks for entering and exiting enabled spans
using `tracing-subscriber::fmt`, comparing them with the overhead of
calling `enter` on an enabled span. Based on this, I've made some
performance improvements. These optimizations include:

- Removing the `HashSet` that's used for tracking previously entered
  span IDs, in favor of linear search. Span stacks probably never deep
  enough for a hashmap to be faster than iterating over a couple of
  vec indices.
- Preallocating the vec used for the span stack to hold at least 64
  elements. This means we'll never have a lag spike from reallocating,
  as I think it'll almost never be deeper than 64 IDs.
- Only cloning/dropping an ID's ref count for the _first_ ID in the stack.

This makes entering and exiting enabled spans significantly faster:
![image](https://user-images.githubusercontent.com/2796466/96798681-3fc85000-13b6-11eb-9e85-7602d918ee09.png)

It would be nice to continue optimizing this, but this might be about
the best it gets given the other requirements that we're now making
assertions about.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

This backports tokio-rs#1062 to v0.1.6. This has already been approved on
master.

hawkw/sharded-slab#45 changes `sharded-slab` so that the per-shard
metadata is allocated only when a new shard is created, rather than all
up front when the slab is created. This fixes the very large amount of
memory allocated by simply creating a new `Registry` without actually
collecting any traces.

This branch updates `tracing-subscriber` to depend on `sharded-slab`
0.1.0, which includes the upstream fix.

In addition, this branch the registry from using `sharded_slab::Slab` to
`sharded_slab::Pool`. This allows us to clear hashmap allocations for
extensions in-place, retaining the already allocated maps. This should
improve `new_span` performance a bit.

Fixes tokio-rs#1005

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

Fixed

- **registry**: Fixed `Registry::new` allocating an excessively large
  amount of memory, most of which would never be used ([tokio-rs#1064])

Changed

- **registry**: Improved `new_span` performance by reusing `HashMap`
  allocations for `Extensions` ([tokio-rs#1064])
- **registry**: Significantly improved the performance of
  `Registry::enter` and `Registry::exit` ([tokio-rs#1058])

[tokio-rs#1064]: tokio-rs#1064
[tokio-rs#1058]: tokio-rs#1058

…s#1080)

This backports PR tokio-rs#1067 to v0.1.x. Since this has already been approved
on master, I'm just going to go ahead and merge it when CI passes.

## Motivation

Currently, the `tracing_subscriber::fmt` module contains only
single-line event formatters. Some users have requested a
human-readable, pretty-printing event formatter optimized for
aesthetics.

## Solution

This branch adds a new `Pretty` formatter which uses an _excessively_
pretty output format. It's neither compact, single-line oriented, nor
easily machine-readable, but it looks _quite_ nice, in my opinion. This
is well suited for local development or potentially for user-facing logs
in a CLI application.

Additionally, I tried to improve the docs for the different formatters
currently provided, including example output. Check out [the Netlify
preview][1]!

[1]: https://deploy-preview-1067--tracing-rs.netlify.app/tracing_subscriber/fmt/index.html#formatters

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

…o-rs#1081) (tokio-rs#1082)

This backports PR tokio-rs#1081 from v0.2.x. Since this has already been approved
on master, I'll just go ahead and merge it when CI passes.

## Motivation

Currently, the `FmtContext` type implements `FormatFields` using the
subscriber's field formatter. However, this is difficult to use. The
`FmtContext` may _not_ be passed to functions expecting a `for<'writer>
FormatFields<'writer>`, because it only implements `FormatFields` for
its _own_ lifetime. This means the writer must have the same lifetime as
the context, which is not correct.

## Solution

This branch fixes this by changing the impl of `FormatFields` for
`FmtContext` to be generic over both the context's lifetime _and_ the
field formatter's lifetime. Additionally, I've added a method for
borrowing the actual field formatter as its concrete type, in case the
`FormatEvent` impl puts additional constraints on its type or is only
implemented for a specific named type, and wants to actually _use_ that
type.

### Fixed

- **fmt**: Fixed wrong lifetime parameters on `FormatFields` impl for
  `FmtContext` ([tokio-rs#1082])

### Added

- **fmt**: `format::Pretty`, an aesthetically pleasing, human-readable
  event formatter for local development and user-facing CLIs ([tokio-rs#1080])
- **fmt**: `FmtContext::field_format`, which returns the subscriber's
  field formatter ([tokio-rs#1082])

[tokio-rs#1082]: tokio-rs#1082
[tokio-rs#1080]: tokio-rs#1080

…okio-rs#1099)

This backports  tokio-rs#1049, which was already approved on master.

## Motivation

Support the latest OpenTelemetry specification

## Solution

In order to support the latest spec, this patch makes the following
breaking API changes:

* Update `opentelemetry` to 0.10.x
* Update `CompatSpan` to reflect changes to `Span` trait
* Record `u64` values as strings as they are no longer supported in
  OpenTelemetry.

Additionally the following non-public api, doc, and example changes:

* Update examples and docs to use new simplified pipeline builder.
* As `opentelemetry::api` no longer exports trace types, internally use
`opentelemetry::trace as otel` to disambiguate from tracing types.
* Remove `rand` dependency as it is no longer needed

Co-authored-by: Eliza Weisman <eliza@buoyant.io>
# Conflicts:
#	examples/examples/opentelemetry-remote-context.rs
#	tracing-opentelemetry/Cargo.toml
#	tracing-opentelemetry/src/layer.rs
#	tracing-opentelemetry/src/span_ext.rs
#	tracing-opentelemetry/src/tracer.rs

…kio-rs#1100)

Closes tokio-rs#648

Install cargo-hack from GitHub release instead of using cache.
See also taiki-e/cargo-hack#89 and
taiki-e/cargo-hack#91.

…#1117)

Currently, we are building and caching `cargo-audit` on CI. The GitHub
Actions configuration we use for caching the `cargo-audit` binary is now
deprecated and is [breaking our CI builds][2].

This PR switches to the [`actions-rs/audit-check` action][3]. This ought
to fix CI.

[1]: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
[2]: https://github.com/tokio-rs/tracing/pull/1116/checks?check_run_id=1444562432
[3]: https://github.com/actions-rs/audit-check

…io-rs#1116)

* chore(deps): update pin-project-lite requirement from 0.1 to 0.2

This backports tokio-rs#1108 to v0.1.x. This was already approved on `master`,
so I'll just merge it pending CI.

Updates the requirements on [pin-project-lite](https://github.com/taiki-e/pin-project-lite) to permit the latest version.
- [Release notes](https://github.com/taiki-e/pin-project-lite/releases)
- [Changelog](https://github.com/taiki-e/pin-project-lite/blob/master/CHANGELOG.md)
- [Commits](taiki-e/pin-project-lite@v0.1.0...v0.2.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>

### Changed

- Updated `pin-project-lite` dependency to 0.2 ([tokio-rs#1108])

[tokio-rs#1108]: tokio-rs#1108

## Motivation

At Netlify we recently introduced native Rust support in the build
system: netlify/build-image#477

## Solution

This PR cleans up the Netlify build config to use a more
straight-forward way of building rust docs.

This also introduces a workaround for
netlify/build-image#505

## Kudos

We're big fans of the `tracing` crate at Netlify and using it for many
new systems recently. Very happy we can give something back!

Closes tokio-rs#1130

…nv_logger compat) (tokio-rs#1126)

Hi Folks,

This PR is about behavior compatibility with the `env_logger` and `log`
crates. There are references in the `tracing-subscriber` docs noting
some level of partial compatibility with `env_logger`, but it is not
clear to me the extent to which that is a priority.

If the intention is to keep the projects close in behavior where there
is overlap in the representations of logging directive strings, then
this PR is a step toward better compatibility.

On the other hand, if such compatibility is more of a short-term
nice-to-have than a long-term objective, then this PR might be a step in
the wrong direction. If so, please feel free to reject it. I happened to
notice the behavior difference (described below) while working on
something else, and just thought I'd bring it up for discussion.

On the *other* other hand, it is clear that some significant effort
*has* been expended to have compatibly parsed logging directive strings.
Which leads me to read the regex code modified in the second commit of
this PR as possibly introducing a level of compatibility that was
deliberately omitted; the existing regex was clearly structured to
accept *only* all uppercase OR *only* all lowercase log level names. So
I'm getting mixed signals :-)

In the end, regardless of the specific outcome of this PR, understanding
the degree to which `env_logger` compatibility is wanted would be useful
to know in general.

For my own use, `env_logger` compatibility is not something I need.


## Motivation

Logging directive strings parsed to create
`tracing_subscriber::filter::env::Directive`s are currently accepted as
all-lower-case or all-upper-case representations of the log level names
(like "info" and "INFO"), but mixed case representation (like "Info",
"iNfo", and "infO") are rejected.

This behavior is divergent with that of the `env_logger` crate, which
accepts the mixed case names. The `env_logger` crate gets the behavior
of parsing mixed case log level names from the underlying `log` crate,
so there may be an element of user expectations involved in that regard,
too, with `log` users expecting that case-insensitive log level names
will be accepted.

Accepting mixed case names would bring the behavior of the
`tracing_subscriber` crate back into alignment those other crates in
this regard.


## Solution

Accept mixed case names for log levels in directive strings.

This PR includes two commits:

   1. The first adds unit tests that demonstrate the mixed case logging
   level names being rejected.

   2. The second introduces an adjustment to `DIRECTIVE_RE` that accepts
   mixed case logging level names. With this change, the tests again all
   pass.

* [1 of 2]: subscriber: add more parse_directives* tests

These test parse_directives() against strings that contain only a
legit log level name. The variants that submit the mixed case forms
are currently failing:

    $ cargo test --lib 'filter::env::directive::test::parse_directives_'
    ...
    failures:
        filter::env::directive::test::parse_directives_global_bare_warn_mixed
        filter::env::directive::test::parse_directives_ralith_mixed

    test result: FAILED. 12 passed; 2 failed; 0 ignored; 0 measured; 61 filtered out

Fix to come in a follow-up commit.

Co-authored-by: Eliza Weisman <eliza@buoyant.io>
 Signed-off-by: Alan D. Salewski <ads@salewski.email>

* [2 of 2]: subscriber: directives: accept log levels in mixed case

Fix issue demonstrated by unit tests in commit f607b7f. With
this commit, the unit tests all pass.

The 'DIRECTIVE_RE' regex now uses a case-insensitive, non-capturing
subgroup when matching log level names in logging directive
strings. This allows correctly capturing not only, e.g., "info" and
"INFO" (both of which were also accepted previously), but also
"Info" and other combinations of mixed case variations for the legit
log level names.

This change makes the behavior of tracing-subscriber more consistent
with that of the `env_logger` crate, which also accepts mixed case
variations of the log level names.

Co-authored-by: Eliza Weisman <eliza@buoyant.io>
 Signed-off-by: Alan D. Salewski <ads@salewski.email>

Update the closing-spans link.

We should allow configuring whether or not to display module_path
or file/line in output.

Co-authored-by: 李小鹏 <lixiaopeng.jetspark@bytedance.com>
Co-authored-by: Jane Lusby <jlusby42@gmail.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>

## Motivation

Tracing's examples depend on a number of external crates that the core
`tracing` crates don't depend on. Sometimes, crates that we only depend
on for examples will break compatibility with our MSRV. It's not ideal
to bump our supported MSRV just for an example, since the actual
`tracing` crates will still build fine.

## Solution

Instead, this PR updates the CI config to exclude examples from the
MSRV check. This way, we don't have to bump MSRV for examples-only
dependencies.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

## Motivation

Fixes the race condition outlined in tokio-rs#1120 . 

## Solution

`Worker` now uses a 2 stage shutdown approach. The first shutdown signal
is sent through the main message channel to the `Worker` from
`WorkerGuard` when it is dropped. Then `WorkerGuard` sends a second
signal on a second channel that is zero-capacity. This means It will
only succeed a `send()` when a `recv()` is called on the other end. This
guarantees that the `Worker` has flushed all it's messages before the
`WorkerGuard` can continue with its drop.

With this solution I'm not able to reproduce the race anymore using the
provided code sample from tokio-rs#1120 

Co-authored-by: Zeki Sherif <zekshi@amazon.com>

…tokio-rs#1031)

Updates the requirements on [crossbeam-channel](https://github.com/crossbeam-rs/crossbeam) to permit the latest version.
- [Release notes](https://github.com/crossbeam-rs/crossbeam/releases)
- [Changelog](https://github.com/crossbeam-rs/crossbeam/blob/master/CHANGELOG.md)
- [Commits](crossbeam-rs/crossbeam@crossbeam-channel-0.4.3...crossbeam-channel-0.5.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>

Changed

- **non_blocking**: Updated `crossbeam-channel` dependency to 0.5
  (tokio-rs#1031)

Fixed
- **non_blocking**: Fixed a race condition when logging on shutdown
  (tokio-rs#1125)
- Several documentation improvements (tokio-rs#1109, tokio-rs#1110, tokio-rs#941, tokio-rs#953)

## Motivation

Support the latest OpenTelemetry specification

## Solution

In order to support the latest spec, this patch makes the following
breaking API changes:

* Update `opentelemetry` to 0.11.x
* Update `OpenTelemetrySpanExt::set_parent` to take a context by value
  as it is now stored and propagated.
* Rename `PreSampledTracer::sampled_span_context` to
  `PreSampledTracer::sampled_context` as it now returns a full otel
  context

Additionally the following doc and example changes:

* Show w3c trace context propagator as recommendation in examples

…1169)

* opentelemetry: prepare for v0.10.0 release

* Update doc links

…#1187)

It turns out that this example never existed on v0.1.x, which is my bad.

Resolves tokio-rs#1179.

…1208)

This branch fixes two known warnings.

The first fixed warning was in `tracing-core/src/callsite.rs`, where
clippy suggested using `std::ptr::eq` to compare addresses instead of
casting `&T` to a `*const T`, which `&T` coerces to _anyways_. Below is
the warning:

```
error: use `std::ptr::eq` when comparing raw pointers
   --> tracing-core/src/callsite.rs:238:9
    |
238 |         self.0 as *const _ as *const () == other.0 as *const _ as *const ()
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `std::ptr::eq(self.0 as *const _, other.0 as *const _)`
    |
    = note: `-D clippy::ptr-eq` implied by `-D warnings`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq
```

The second fixed warning is a bit more complex. As of Rust 1.50,
[`AtomicUsize::compare_and_swap`][1] has been deprecated in favor of
[`AtomicUsize::compare_exchange`][2] and
[`AtomicUsize::compare_exchange_weak`][3]. I've moved
`tracing_core::dispatch::set_global_default` to use
`AtomicUsize::compare_exchange` as `AtomicUsize::compare_exchange_weak`
is designed for atomic loads in loops. Here are a few notes on the
differences between `AtomicUsize::compare_and_swap` and
`AtomicUsize::compare_exchange`:
- `AtomicUsize::compare_exchange` returns a result, where the
  `Result::Ok(_)` branch contains the prior value. This is equivalent
  to the now-deprecated [`AtomicUsize::compare_and_swap`][1] returning
  the `current` parameter upon a successful compare-and-swap operation,
  but success is now established through a `Result`, not an equality
  operation.
- `AtomicUsize::compare_exchange` accepts an `Ordering` for the failure
  case of a compare-and-swap. The [migration guide suggests][4] using
  `Ordering::SeqCst` for both the success and failure cases and I saw
  no reason to depart from its guidance.

After this branch is approved, I'll backport these fixes to the `v0.1.0` branch.

[1]: https://doc.rust-lang.org/nightly/std/sync/atomic/struct.AtomicUsize.html#method.compare_and_swap
[2]: https://doc.rust-lang.org/nightly/std/sync/atomic/struct.AtomicUsize.html#method.compare_exchange
[3]: https://doc.rust-lang.org/nightly/std/sync/atomic/struct.AtomicUsize.html#method.compare_exchange_weak
[4]: https://doc.rust-lang.org/nightly/std/sync/atomic/struct.AtomicUsize.html#migrating-to-compare_exchange-and-compare_exchange_weak

…1207)

This avoids relatively heavy dependencies (`tracing-attributes`, `syn`,
etc.) in some cases.

## Motivation

From the readme

> (if you're the maintainer of a tracing ecosystem crate not in this list, please let us know!)

## Solution

Added links to tracing-elastic-apm.

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

Currently, when the `log` feature is enabled but the `log-always`
feature is not, we check the (dynamic, but inexpensive)
`dispatch::has_been_set` variable **before** checking if the event's
level would be enabled by `log`'s static max level features.

Although this check is not terribly costly in terms of performance, it
*does* result in code being generated even when the `log` crate disables
some levels statically. This means that we will always generate *some*
code when the `log` feature is disabled. This isn't ideal --- the static
max level features should result in us generating *no* code whatsoever
for disabled trace points.

This commit moves the static max level check outside of the dispatch
check. Now, we should generate 0 bytes of assembly when both `log` and
`tracing` disable an event with their static filtering features.

I've also updated the docs to explain the relationship between `tracing`
and `log`'s separate static filtering.

Fixes tokio-rs#1174

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

* Add sample implementation of `FormatEvent`

The docs previously didn't provide much help implementing `FormatEvent`.
Especially getting access to fields on spans could be tricky unless the
user was aware of `FormattedFields`.

This updates the docs with a basic, but working, example.

* Apply suggestions from code review

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

* Add comment explaining what `FormattedFields` is

* Expand docs a bit

* Fix formatting

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

…#1038)

Updates the requirements on [pin-project](https://github.com/taiki-e/pin-project) to permit the latest version.
- [Release notes](https://github.com/taiki-e/pin-project/releases)
- [Changelog](https://github.com/taiki-e/pin-project/blob/master/CHANGELOG.md)
- [Commits](taiki-e/pin-project@v0.4.0...v1.0.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

- this allows dropping the old time 0.1 dependency (see https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#0416)

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

The `tracing-attributes` documentation for `instrument` is out of date
and could use some improvement. In particular, it doesn't mention that
empty fields can be created in `instrument`'s `fields` argument, and
states that dotted fields are forbidden and that field values must be
literals, both of which are no longer the case. See also tokio-rs#1210 and
tokio-rs#1211.

This branch updates the docs to correct the false statements, and also
fleshes out the usage examples a bit.

I wasn't sure what to do with the old examples --- some of them are now
redundant, but it's also useful to have a big list of examples for every
allowed form. Any thoughts?

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

This patch resolves the field value capitalization ambiguity currently
in `otel.kind` by instead recommending an enum value. This also brings
type safety to the value, further reducing the risk of typos and other
misuse.

Resolves tokio-rs#1209

…1167)

Motivation
----------

The closure generated by `#[instrument(err)]` for non-async functions is
not mutable, preventing any captured variables from being mutated. If a
function has any mutable parameters that are modified within the
function, adding the `#[instrument(err)]` attribute will result in a
compiler error.

Solution
--------

This change makes it so the closure is executed directly as a temporary
variable instead of storing it in a named variable prior to its use,
avoiding the need to explicitly declare it as mutable altogether or to
add an `#[allow(unused_mut)]` annotation on the closure declaration to
silence lint warnings for closures that do not need to be mutable.

### Fixed

- Compiler error when using `#[instrument(err)]` on functions with
  mutable parameters ([tokio-rs#1167])
- Missing function visibility modifier when using `#[instrument]` with
  `async-trait` ([tokio-rs#977])
- Multiple documentation fixes and improvements ([tokio-rs#965], [tokio-rs#981],
  [tokio-rs#1215])

 ### Changed

- `tracing-futures` dependency is no longer required when using
  `#[instrument]` on async functions ([tokio-rs#808])

Thanks to @nagisa, @Txuritan, @TaKO8Ki, and @okready for contributing to
this release!

[tokio-rs#1167]: tokio-rs#1167
[tokio-rs#977]: tokio-rs#977
[tokio-rs#965]: tokio-rs#965
[tokio-rs#981]: tokio-rs#981
[tokio-rs#1215]: tokio-rs#1215
[tokio-rs#808]: tokio-rs#808

This branch updates the minimum `tracing-attributes` dependency from
v0.1.10 to v0.1.12. v0.1.12 includes a number of significant changes:

* Support for arbitrary field expressions in `#[instrument]` was added
  in v0.1.11. This means that users who read the crates.io docs for
  `tracing-attributes` will see that arbitrary field expressions are
  permitted, but if `tracing` reexports an older version, this won't
  actually work.
* v0.1.12 updates `#[instrument]` to use the `Instrumented` type from
  `tracing` rather than from `tracing-futures`. This means async/await
  will now work without an additional dependency on `tracing-futures`.
* Also, a few bugs were fixed in v0.1.11 and v0.1.12.

### Fixed

- **attributes**: Compiler error when using `#[instrument(err)]` on
  functions with mutable parameters ([tokio-rs#1167])
- **attributes**: Missing function visibility modifier when using
  `#[instrument]` with `async-trait` ([tokio-rs#977])
- **attributes** Removed unused `syn` features ([tokio-rs#928])
- **log**: Fixed an issue where the `tracing` macros would generate code
  for events whose levels are disabled statically by the `log` crate's
  `static_max_level_XXX` features ([tokio-rs#1175])
- Fixed deprecations and clippy lints ([tokio-rs#1195])
- Several documentation fixes and improvements ([tokio-rs#941], [tokio-rs#965], [tokio-rs#981],
  [tokio-rs#1146], [tokio-rs#1215])

### Changed

- **attributes**: `tracing-futures` dependency is no longer required
  when using `#[instrument]` on async functions ([tokio-rs#808])
- **attributes**: Updated `tracing-attributes` minimum dependency to
  v0.1.12 ([tokio-rs#1222])

Thanks to @nagisa, @Txuritan, @TaKO8Ki, @okready, and @krojew for
contributing to this release!

The `:` breaks the last three links in the changelog

…okio-rs#1236)

This backports PR tokio-rs#1233 to v0.1.x. This isn't *just* a simple cherry-pick
because the new tests in that branch use the v0.2.x module names, so
that had to be fixed. Otherwise, though, it's the same change, and I'll go
ahead and merge it when CI passes, since it was approved on `master`.

## Motivation

Currently, using `#[instrument(err)]` on a function returning a `Result`
with an `impl Trait` in it results in a compiler error. This is because
we generate a type annotation on the closure in the function body that
contains the user function's actual body, and `impl Trait` isn't allowed
on types in local bindings, only on function parameters and return
types.

## Solution

This branch fixes the issue by simply removing the return type
annotation from the closure. I've also added tests that break on master
for functions returning `impl Trait`, both with and without the `err`
argument.

Fixes tokio-rs#1227

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

# 0.2.5 (February 16, 2021)

### Changed

- Updated `pin-project` dependency to 1.0 ([tokio-rs#1038])

### Fixed

- Several documentation fixes and improvements ([tokio-rs#832], [tokio-rs#911], [tokio-rs#913],
  [tokio-rs#941], [tokio-rs#953], [tokio-rs#981])

[tokio-rs#1038]: https://github.com/tokio-rs/tracing/pulls/1038
[tokio-rs#832]: https://github.com/tokio-rs/tracing/pulls/832
[tokio-rs#911]: https://github.com/tokio-rs/tracing/pulls/911
[tokio-rs#913]: https://github.com/tokio-rs/tracing/pulls/913
[tokio-rs#941]: https://github.com/tokio-rs/tracing/pulls/941
[tokio-rs#953]: https://github.com/tokio-rs/tracing/pulls/953
[tokio-rs#981]: https://github.com/tokio-rs/tracing/pulls/981

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

…okio-rs#1232)

The `instrument` macro does not explain the syntax that can be used and
the main tracing docs only say that this syntax is valid for `span` and
`event` macros.

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

…-rs#1242)

This PR fixes the event macros to accept syntax like
`info!(target: "test", ?value)`. While this works without the explicit
`target`, it did not worked with the `target` up to now. Besides that
the macros also used from wrong levels in certain branches.

Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>

### Fixed

- Compiler error when using `#[instrument(err)]` on functions which
  return `impl Trait` ([tokio-rs#1236])

[tokio-rs#1236]: tokio-rs#1236

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

### Fixed

- **attributes**: Compiler error when using `#[instrument(err)]` on
  functions which return `impl Trait` ([tokio-rs#1236])
- Fixed broken match arms in event macros ([tokio-rs#1239])
- Documentation improvements ([tokio-rs#1232])

Thanks to @bkchr and @lfranke for contributing to this release!

[tokio-rs#1236]: tokio-rs#1236
[tokio-rs#1239]: tokio-rs#1239
[tokio-rs#1232]: tokio-rs#1232

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

This branch adds a check against the current value of the max global
`LevelFilter` hint in `tracing_log`'s `LogTracer::enabled` method. This
should prevent `log::${LEVEL}_enabled!` from always returning `true`
when `tracing` is in use, fixing a performance issue when consuming
`log` records from tracing (see bytecodealliance/wasmtime#2662).

This does, however, mean `LogTracer::enabled` will always be called if
the max `log` level is not set. We can't determine whether we can set
`log`'s max level in `tracing_log`, since we don't know if subscribers
will change (resulting in the current max `tracing` level filter
changing), or if the current subscriber is set as the global default.
Higher-level code in `tracing_subscriber` can do this, though, in
`init()`, because it _does_ know that it's setting a global default.
I'll add that in a follow-up PR.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

Depends on tokio-rs#1247.

Since `tracing-subscriber`'s `init` and `try_init` functions set the
global default subscriber, we can use the subscriber's max-level hint as
the max level for the log crate, as well. This should significantly
improve performance for skipping `log` records that fall below the
collector's max level, as they will not have to call the
`LogTracer::enabled` method.

This will prevent issues like bytecodealliance/wasmtime#2662
from occurring in the future. See also tokio-rs#1249.

In order to implement this, I also changed the `FmtSubscriber`'s
`try_init` to just use `util::SubscriberInitExt`'s `try_init` function,
so that the same code isn't duplicated in multiple places. I also
added `AsLog` and `AsTrace` conversions for `LevelFilter`s in
the `tracing-log` crate.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

The `FmtCollector` type is missing a `Collect::max_level_hint
method that forwards the inner stack's max level hint.

This fixes that, and adds tests.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

PRs tokio-rs#1247, tokio-rs#1248, and tokio-rs#1251 improve `tracing`'s behavior for the `log`
crate's `log_enabled!` macro when a max-level hint is set. However, this
*doesn't* get us correct behavior when a particular target is not
enabled but the level is permitted by the max-level filter. In this
case, `log_enabled!` will still return `true` when using `LogTracer`,
because it doesn't currently call `Subscriber::enabled` on the current
subscriber in its `Log::enabled` method. Instead, `Subscriber::enabled`
is only checked when actually recording an event.

This means that when a target is disabled by a target-specific filter
but it's below the max level, `log::log_enabled!` will erroneously
return `true`. This also means that skipping disabled `log` records in
similar cases will construct the `log::Record` struct even when it isn't
necessary to do so.

This PR improves this behavior by adding a call to `Subscriber::enabled`
in `LogTracer`'s `Log::enabled` method. I've also added to the existing
tests for filtering `log` records to ensure that we also handle the
`log_enabled!` macro correctly.

While I was here, I noticed that the `Log::log` method for `LogTracer`
is somewhat inefficient --- it gets the current dispatcher *three*
times, and checks `enabled` twice. Currently, we check if the event
would be enabled, and then call the`format_trace` function, which *also*
checks if the event is enabled, and then dispatches it if it is. This is
not great. :/ I fixed this by moving the check-and-dispatch inside of a
single `dispatcher::get_default` block, and removing the duplicate
check.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

Added

- Re-export the `log` crate so that users can ensure consistent versions
  ([tokio-rs#602])
- `AsLog` implementation for `tracing::LevelFilter` ([tokio-rs#1248])
- `AsTrace` implementation for `log::LevelFilter` ([tokio-rs#1248])

Fixed

- **log-tracer**: Fixed `Log::enabled` implementation for `LogTracer`
  not calling `Subscriber::enabled` ([tokio-rs#1254])
- **log-tracer**: Fixed `Log::enabled` implementation for `LogTracer`
  not checking the max level hint ([tokio-rs#1247])
- Several documentation fixes ([tokio-rs#483], [tokio-rs#485], [tokio-rs#537], [tokio-rs#595], [tokio-rs#941],
  [tokio-rs#981])

[tokio-rs#483]: https://github.com/tokio-rs/tracing/pulls/483
[tokio-rs#485]: https://github.com/tokio-rs/tracing/pulls/485
[tokio-rs#537]: https://github.com/tokio-rs/tracing/pulls/537
[tokio-rs#595]: https://github.com/tokio-rs/tracing/pulls/595
[tokio-rs#605]: https://github.com/tokio-rs/tracing/pulls/604
[tokio-rs#941]: https://github.com/tokio-rs/tracing/pulls/941
[tokio-rs#1247]: https://github.com/tokio-rs/tracing/pulls/1247
[tokio-rs#1248]: https://github.com/tokio-rs/tracing/pulls/1248
[tokio-rs#1254]: https://github.com/tokio-rs/tracing/pulls/1254

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

### Fixed

- **env-filter**: Fixed directives where the level is in mixed case
  (such as `Info`) failing to parse ([tokio-rs#1126])
- **fmt**: Fixed `fmt::Subscriber` not providing a max-level hint
  ([tokio-rs#1251])
- `tracing-subscriber` no longer enables `tracing` and `tracing-core`'s
  default features ([tokio-rs#1144])

### Changed

- **chrono**: Updated `chrono` dependency to 0.4.16 ([tokio-rs#1189])
- **log**: Updated `tracing-log` dependency to 0.1.2

Thanks to @salewski, @taiki-e, @davidpdrsn and @markdingram for
contributing to this release!

[tokio-rs#1126]: tokio-rs#1126
[tokio-rs#1251]: tokio-rs#1251
[tokio-rs#1144]: tokio-rs#1144
[tokio-rs#1189]: tokio-rs#1189

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

…-rs#1252)

* Simplify common case of immediately entering the span

This PR allows the following API:

```
let _guard = tracing::span!("foo").entered();
```

See tokio-rs#1246 for an extended
discussion.

* Add missing inlines

This fns are monomorphic, so an `#[inline]` is necessary to alow
cross-crate inlining at all.

* improve method documentation

Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

Added

- `Span::entered` method for entering a span and moving it into a guard
  by value rather than borrowing it (tokio-rs#1252)

Thanks to @matklad for contributing to this release!

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

…okio-rs#1228) (tokio-rs#1291)

This backports tokio-rs#1228 from `master` to `v0.1.x`.

It works with both the old and new version of async-trait (except for
one doc test that failed previously, and that works with the new
version). One nice thing is that the code is simpler (e.g.g no self
renaming to _self, which will enable some simplifications in the
future).

A minor nitpick is that I disliked the deeply nested pattern matching in
get_async_trait_kind (previously: get_async_trait_function), so I
"flattened" that a bit.

Fixes  tokio-rs#1219.

Co-authored-by: Simon THOBY <git@nightmared.fr>

### Fixed

- Compatibility between `#[instrument]` and `async-trait` v0.1.43 and
  newer ([tokio-rs#1228])

Thanks to @nightmared for lots of hard work on this fix!

[tokio-rs#1228]: tokio-rs#1228

…okio-rs#1103)

I reckon this is a bug, and @samschlegel fixed this for ChronoUtc,
but not for ChronoLocal.

…okio-rs#1289)

This backports tokio-rs#1289 from `master`.

This PR aims to remove a lot of initializer boilerplate code by adopting
the`struct update syntax.  If the [RFC 2528]  gets merged and
implemented, we can remove more. 😸

[RFC 2528]: rust-lang/rfcs#2528

As far as I can tell, we are not relying on transparency anywhere, so
using this rather refined feature here is confusing.

…kio-rs#1290)

This backports PR tokio-rs#1290 from `master`.

…utures (tokio-rs#1297)

This backports tokio-rs#1297 from `master`.

Fixes tokio-rs#1296.

I had forgotten to use all the input statements in tokio-rs#1228, so we would
delete nearly all the statement of sync functions that return a boxed
future :/

## Motivation

This fixes tokio-rs#1212, where extra padding was written when logging with the
pretty formatter.

## Solution 

With this change we only write padding when we actually decide to write
a value but not when skipping a metadata value such as `log.file` or
`log.line`

This backports tokio-rs#1277 from `master`.

Fixes tokio-rs#1136.

Allows arbitrarily combining different FmtSpan events to listen to.

Motivation
----------

The idea is to allow any combination of `FmtSpan` options, such as the
currently unachievable combination of `FmtSpan::NEW | FmtSpan::CLOSE`.

Solution
--------

Make `FmtSpan` behave like a bitflag that can be combined using the
bitwise or operator ( `|` ) while maintaining backward compatibility by
keeping the same names for all existing presets and keeping the
implementation details hidden.

This backports tokio-rs#1240 from `master`.

* subscriber: update pretty formatter for no ansi

 ## Background

    Currently, when the `Pretty` event formatter is being used, it does
    not change its output when the `with_ansi` flag is set to false by
    the `CollectorBuilder`.

 ## Overview

    While this formatter is generally used in situations such as local
    development, where ANSI escape codes are more often acceptable,
    there are some situations in which this can lead to mangled output.

    This commit makes some minor changes to account for this `ansi` flag
    when formatting events using `Pretty`.

    Becuase ANSI codes were previously used to imply the event level
    using colors, this commit additionally modifies `Pretty` so that
    it respects `display_level` when formatting an event.

 ## Changes

    * Changes to `<Format<Pretty, T> as FormatEvent<C, N>>::format_event`

    * Add a `PrettyVisitor::ansi` boolean flag, used in its `Visit`
      implementation.

        * Add a new `PrettyVisitor::with_ansi` builder pattern method to
          facilitate this.

 ## Out of Scope

    One detail worth nothing is that this does not solve the problem of
    *fields* being formatted without ANSI codes. Configuring a
    subscriber using this snippet would still lead to bolded fields in
    parent spans.

```rust
tracing_subscriber::fmt()
    .pretty()
    .with_ansi(false)
    .with_level(false)
    .with_max_level(tracing::Level::TRACE)
    .init();
```

    This can be worked around by using a different field formatter, via
    `.fmt_fields(tracing_subscriber::fmt::format::DefaultFields::new())`
    in the short-term.

    In the long-term, tokio-rs#658 is worth investigating further.

Refs: tokio-rs#658

# 0.1.15 (March 12, 2021)

### Fixed

- `#[instrument]` on functions returning `Box::pin`ned futures incorrectly
  skipping function bodies prior to returning a future ([tokio-rs#1297])

Thanks to @nightmared for contributing to this release!

[tokio-rs#1297]: tokio-rs#1297

# 0.2.17 (March 12, 2020)

### Fixed

- **fmt**: `Pretty` formatter now honors `with_ansi(false)` to disable
  ANSI terminal formatting ([tokio-rs#1240])
- **fmt**: Fixed extra padding when using `Pretty` formatter ([tokio-rs#1275])
- **chrono**: Removed extra trailing space with `ChronoLocal` time
  formatter ([tokio-rs#1103])

### Added

- **fmt**: Added `FmtContext::current_span()` method, returning the
  current span
  ([tokio-rs#1290])
- **fmt**: `FmtSpan` variants may now be combined using the `|` operator
  for more granular control over what span events are generated
  ([tokio-rs#1277])

Thanks to new contributors @cratelyn, @dignati, and @zicklag, as well as
@Folyd, @matklad, and @najamelan, for contributing to this release!

[tokio-rs#1240]: tokio-rs#1240
[tokio-rs#1275]: tokio-rs#1275
[tokio-rs#1103]: tokio-rs#1103
[tokio-rs#1290]: tokio-rs#1290
[tokio-rs#1277]: tokio-rs#1277

This backports PR tokio-rs#1335 from `master` to `v0.1.x`.

Clippy now warns about implementing `Into` rather than `From`, since
`From` automatically provides `Into` but `Into` does not provide `From`.

This commit fixes the direction of those conversions, placating Clippy.

Additionally, it fixes a redundant use of slice syntax that Clippy also
complained about.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

This branch changes the `field_filter_events` and `field_filter_spans`
tests in `tracing-subscriber` to be ignored by default, as they often
fail spuriously on CI.

The tests can still be run using
```shell
$ RUSTFLAGS="--cfg flaky_tests" cargo test
```
or similar.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

This was not fixed in tokio-rs#1335 because the `Into<Id> for Span` conversion
was removed in v0.2.x.

This should make clippy happy on v0.1.x.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

This backports tokio-rs#1322 from `master` to `v0.1.x`,

* opentelemetry: support otel 0.13.0

Switches to `Cow<'static, str>` for otel event names and updates docs to
show simplified install methods.

* Add simple vs batch comment

Co-authored-by: Julian Tescher <jatescher@gmail.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>

## Motivation

Optional inactivity tracking should have minimal overhead when disabled.

## Solution

Check to see if inactivity tracking is enabled before doing more
expensive operations. Performance improvement of ~6% using current
benchmarks.

* Address comments and switch to i64 timing values

Authored-by: Julian Tescher
Co-authored-by: Eliza Weisman <eliza@buoyant.io>

## Motivation

Fix a broken link for `#[instrument]`. Also, fix a minor typo (`initalized` ->
 `initialized`).

…okio-rs#1333)

Serializing a spans `on_ACTION` events, when no fields are set on the
span, results in invalid JSON. This is because `serializier_map` was
getting a size hint for `self.0.metadata().fields().len()` then
serializing `self.0.fields.field_set()` instead. This resulted in the
fields key being set to an empty object, then Serde serializes the k/v
pairs from `field_set()`. This was causing an erroneous closing brace
`}` to be added after the serialized fields.

This change aligns the size hint with the actual serialized data.

Refs: tokio-rs#829 (comment)

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

…1342)

# 0.12.0 (March 31, 2021)

### Breaking Changes

- Upgrade to `v0.13.0` of `opentelemetry` (tokio-rs#1322)
  For list of breaking changes in OpenTelemetry, see the
  [v0.13.0 changelog](https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry/CHANGELOG.md#v0130).

### Changed

- Improve performance when tracked inactivity is disabled (tokio-rs#1315)

## Motivation

Understand the overhead added by recording OpenTelemetry data so that it
can be minimized.

## Solution

Add criterion benchmarks, initially tracking request/response style
workloads (1 main span with 99 children).

This patch adds benchmarks for standard `tracing-opentelemetry` usage,
as well as baselines for understanding the overhead specific to the
usage of the otel tracer, and registry span access patterns.

)

* subscriber: fix span data for new, exit, and close events

New, exit and close span events are generated while the current
context is set to either `None` or the parent span of the span the
event relates to. This causes spans data to be absent from the JSON
output in the case of the `None`, or causes the span data to reference
the parent's span data. Changing the way the current span is
determined allows the correct span to be identified for these
events. Trying to access the events `.parent()` allows access of the
correct span for the `on_event` actions, while using `.current_span()`
works for normal events.

Ref: tokio-rs#1032

* Fix style

* subscriber: improve test for tokio-rs#1333

Based on feedback by @hawkw, I've improved the test for tokio-rs#1333 to parse
the json output. This is more specifc for the bug and allows easier
testing of the different span `on_events`.

Ref: tokio-rs#1333 (review)

* subscriber: improve tokio-rs#1334 tests covering all span states

Use the `on_records` test method check all events have the correct
context as described in the PR.

* Apply suggestions from code review

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

The following two patterns for the `event!()` are identical to each
other, and the second one swapped the order of `$lvl` and `parent:
$parent` which I don't think is correct. 
```rust
    (parent: $parent:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => (
        $crate::event!(
            target: module_path!(),
            parent: $parent,
            $lvl,
            { message = format_args!($($arg)+), $($fields)* }
        )
    );
    (parent: $parent:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => (
        $crate::event!(
            target: module_path!(),
            $lvl,
            parent: $parent,
            { message = format_args!($($arg)+), $($fields)* }
        )
    );
```

I found the duplicated via
[macro_railraod](https://github.com/lukaslueg/macro_railroad). Here is
the diagram: 

![image](https://user-images.githubusercontent.com/3369694/114296705-47ec8700-9adf-11eb-971f-f485329d0339.png)