## Motivation
Fix minimal-versions failure.
## Solution
Upgrade all the dependencies to their most recent semver-compatible
version, adjusting back down as necessary for MSRV.
Essentially a cherry-pick of #2231, but redone by hand.
## Tests
- `cargo minimal-versions msrv verify -- cargo check --all-features`
- `cargo minimal-versions msrv verify -- cargo check --no-default-features`
## Methodology
- `cargo update && cargo upgrade --to-lockfile`
- Identify [a bug](https://github.com/killercup/cargo-edit/issues/750) and manually resolve it
- loop; upgrade transitive deps
- `cargo minimal-versions check --all-features`
- Identify failing dep
- `cargo minimal-versions tree -i dep --all-features`
- Find the closest dependency leading to pulling in `dep`
- `cargo add fixdep --optional` to force a more recent more-minimal-versions-correct version
- loop; downgrade to msrv
- `cargo minimal-versions msrv verify -- cargo check --all-features`
- Identify failing dep
- `cargo minimal-versions tree -i dep --all-features`
- Find the version that supports MSRV from lib.rs
- `cargo upgrade dep@msrv`
This updates all crates' MSRVs to 1.49 if they were not already greater
than that (`tracing-appender` is at 1.53). Rust 1.49+ is required to
update `parking_lot` to v0.12 (see #1878). Also, `futures-task` (which I
believe is only needed as a transitive dep) now needs 1.45+, so this
also fixes our CI build.
Because `tracing-opentelemetry` previously required 1.46.0, it had a
separate CI MSRV job. Since 1.49.0 is greater than 1.46.0, the separate
check for `tracing-opentelemetry` is no longer needed.
In the process, I removed deprecated uses of
`core::atomic::spin_loop_hint`, which is replaced with
`core::hint::spin_loop` in 1.49.
## Motivation
Currently, our MSRV CI build is broken because of the `tracing-tower`
crate, which depends on `http`. The latest `http` release broke support
for Rust 1.42.0.
Since the `tracing-tower` crate is unreleased and is probably never
going to be published in its current form (see #238), this isn't
actually an issue, but the CI breakage is quite sad. I'm working on an
upstream PR to `tower` to add tracing support there, so we can
eventually deprecate the `tracing-tower` crate and direct users to
upstream. However, that's not quite ready.
Also, we should probably just drop the `http` support from
`tracing-tower` entirely, since tracing HTTP requests with `Tower`
services is probably better served by the `tower-http` crate's [`trace`
middleware][1]. This middleware is significantly more featureful.
[1]: https://docs.rs/tower-http/0.1.1/tower_http/trace/index.html
## Solution
For now, this branch just makes the `http` feature flag on
`tracing-tower` off by default, instead of on by default. This may break
git deps, but this crate was never officially stable. Doing this should
fix CI.
## Alternatives
We could also just modify the `check-msrv` CI job to test every crate
_except_ for `tracing-tower`. This would be a bit of a pain but wouldn't
break any git deps that use tracing-tower's http feature...
This branch fixes some minor RustDoc issues. In particular:
- The `broken_intra_doc_links` lint was renamed to
`rustdoc::broken_intra_doc_links`. This generates a warning, since the
old name was deprecated.
- `ignore` code blocks are specifically for _Rust_ code that should not
be compiled, not for other text blocks. We were using `ignore` on JSON
blocks, which generates a warning.
- A bunch of links in `tracing-subscriber`'s RustDocs were broken. This
fixes that.
I also changed the Netlify configuration to run with `-D warnings`, so that
we can surface RustDoc warnings in CI builds.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* futures: Replace pin-project by pin-project-lite
* tower: Replace pin-project by pin-project-lite
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: David Barsky <me@davidbarsky.com>
This branch fixes some annoying new clippy lints no one cares about.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
# Conflicts:
# tracing-subscriber/src/layer.rs
## Motivation
In order to get a compiler warning (or error) when links are broken.
Closes#940
## Solution
- [x] add `deny(broken_intra_doc_links)`
- [x] add a note to the CONTRIBUTING.md documentation on building docs locally
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
This changes the logo to a wordmark. This should be consistent
with the ones for all the other Tokio crates, when we add them
elsewhere.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The MIT license states:
> The above copyright notice and this permission notice
> shall be included in all copies or substantial portions
> of the Software.
## Solution
Therefore the LICENSE files should be present in each crate directory,
so they are included with `cargo publish`.
Now that the new https://tokio.rs is live, we can add the new Tracing
logo to the RustDoc!
I also added a couple missing `html_root_url` attributes in published
crates.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
It looks like Rust 1.43's version of clippy added a new lint for
redundant `use` statements with just a crate name. These are unnecessary
because the root module of an external crate is always available without
imports. Apparently, `tracing-log`, `tracing-subscriber`, `tracing`, and
`tracing-tower` all had some redundant `use` statements, which clippy now
warns us about.
## Solution
This PR removes them.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, `tracing` uses GitHub Actions for CI. However, we have
previously used both Travis and Azure Pipelines CI. Some artifacts of
previous CI configurations, such as badges and config files, still exist
in the repo. This can be confusing, since some of these CI
configurations imply things that aren't currently true (such as old MSRV
versions).
## Solution
This branch removes the following:
- Azure Pipelines badges from cargo metadata. These currently show up
as "never built" on crates.io, since the Azure build is turned off. So, we
should just remove them.
- `.travis.yml`. We don't use Travis and there's no sense keeping around
an old config file.
- `azure-pipelines.yml`. Similarly, we no longer need this.
Fixes: #669
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Intra-workspace dependencies can go out of sync if only referencing
crates.io, where changing one crate locally and testing the whole
library will result in errors stemming from two different versions of
the same trait etc. This is hard to keep track of and makes development
more difficult than it needs to be.
## Solution
Afaik it's common practice to specify both a version and a path as per
[the cargo docs][1]. This is what tokio does with its subcrates too.
[1]: https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/specifying-dependencies.md#multiple-locations.
* 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, 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>
This branch prepares for an initial stable release of `tracing-futures`.
I've done some pre-release cleanup and docs work as well as updating
versions.
* futures: improve docs
* futures: pre-release cleanup
* futures: update futures-preview version
* futures: nicer readme/lib docs
* fix breaky path dep
* also fix examples path dep
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
These examples were moved in #316, but apparently I forgot to delete
the dev dependencies in some Cargo.tomls.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, most crates in this repository have `examples` directories
that contain demonstrations of how to use that crate. In many cases,
these examples also use APIs from _other_ crates in this repository ---
for example, the `tracing-subscriber` `FmtSubscriber` is used by many
examples to format the output generated by instrumentation APIs, so that
users can see the generated output.
The disadvantage to this approach is that it requires crates in this
repository to have dev-dependencies on each other. This is problematic
for a few reasons:
* It makes it easy to inadvertently create cyclic dependencies between
`tracing` crates.
* When building a crate that depends on a crate with dev-dependencies,
those dev-dependencies are downloaded and compiled, despite not being
linked into the dependent crate. This means that users depending on a
tracing crate will pull in a larger dependency tree, since the
dev-dependencies used by examples are also downloaded, although they
are not required by the dependent. This makes the tracing crate
appear to be a much larger dependency than it actually is, and can
make users' build times slower.
* Finally, it means that the examples are scattered throughout the
repository. In some cases, the examples demonstrate the functionality
of multiple crates, but only live in one crate's `examples` dir. This
can hurt the discoverability of the examples, especially for new
users.
## Solution
This branch moves all the examples out of individual crates and into a
new `examples` crate (which is otherwise empty and cannot be published
to crates.io). The `examples` crate is part of the root `tracing`
workspace, so it's still possible to `cargo run --example WHATEVER`.
Similarly, `cargo test --all` will still build the examples.
All dev-dependencies which were only required by examples and not tests
have been removed, which has a drastic impact on the dependency
footprint of some crates.
Finally, I've added a README to the `examples` crate, listing the
available examples and what functionality they demonstrate.
Refs: #315, #308
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
In the near future, the `tracing-subscriber` crate should be ready for a
stable 0.1 release. Before we can do that, we should do some pre-release
polish, such as denying warnings, updating idioms, and adding missing
documentation.
This branch performs most of the necessary polish for
`tracing-subscriber`. Please note the following:
* The next release will not be version 0.1, as PR #241 would be a
breaking change, and I'd like to land that first. We'll probably do
an alpha.4 first.
* I didn't add `deny(warnings)`, as that will also deny deprecation
warnings, and I've had bad experiences with deprecations breaking
CI in the past. Instead, I've denied most other warnings explicitly.
The downside to this is a *very* long list of deny attributes.
* The docs added in this branch are pretty rough. It would be good to
expand them some more in the future, hopefully before 0.1.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## 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>
This commit tweaks the `tracing-tower` load-generator example a little
to better simulate a real application under load. In particular, there
are now three load generators rather than a single one, and there is a
small amount of random jitter to when each load generator sends a
request. This has the effect of making events more likely to be
interleaved, so filtering becomes much more necessary.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Some Tracing examples, especially in unstable crates, were written
against earlier versions of `tracing`. They don't always demonstrate
the most idiomatic use of Tracing APIs.
## Solution
This updates the examples to use newer Tracing APIs and syntax. Now, the
examples will demonstrate the preferred idioms.
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
A new alpha release of `tracing-subscriber` that contains the new
dynamic field filtering layer has been requested by several users.
Unfortunately, we cannot publish the current master state of
`tracing-subscriber`, as the load-generator example that demonstrates
dynamic field filtering depends on `tracing-tower`, which is unreleased.
## Solution
This branch moves the load-generator example from `tracing-subscriber`'s
examples directory to `tracing-tower`s. This way, `tracing-subscriber`
need no longer depend on `tracing-tower`.
Since the example is intended to demonstrate `tracing-subscriber`
functionality, we should probably move it back when `tracing-tower` is
released.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, `tracing-fmt` provides an implementation of `env_logger`-like
filtering directives. However, there are two issues:
1. The implementation is specific to `tracing-fmt` and does not work
with other subscribers.
2. Filtering dynamically based on field values is not supported.
Now that the `Layer` type has been added to `tracing-subscriber` (see
#136), we can implement filtering generically, as a `Layer` that can
wrap other `Subscriber`s to provide a particular filtering strategy.
## Solution
This branch re-implements the `env_logger` style filtering in
`tracing-fmt` as a `tracing-subscriber::Layer`. The new `Layer` type
implements dynamic filtering on span fields, in addition to the
functionality of the `tracing-fmt` implementation. I've also added a
wrapper type to support runtime reloading of a `Layer`, similarly to
the `Reload` type in `tracing-fmt::filter`, but more general.
Finally, I've added some tests and an interactive demo for the new
filtering. The example runs a simple web service with a load generator,
and allows users to explore the `tracing-fmt` output from the example
service by dynamically reloading the filter settings.
## Notes
This is admittedly a pretty large branch, but I think it makes the
most sense to merge everything together, since the example requires
both the filter implementation *and* the reload layer. I've tried to
make sure the most complex bits of the filtering code has comments
describing the implementation, but please let me know if anything
is unclear.
Also, there is a lot of room for potential performance improvements
in the current filter implementation. I've left comments on some code
that I think could probably be made more efficient. Ideally, though,
any future optimization work ought to be guided by benchmarks as well.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch makes a few small README and Cargo.toml changes:
* Add Azure Pipelines build status badges to Cargo.tomls
* Change README build status badges to Azure Pipelines
* Add "maintenance: experimental" badges to unreleased crates
* Link to `tracing` docs and crates.io page in the root README,
rather than `tracing-core`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The `MakeService` type in `tracing_tower::service_span` was
missing a `Clone` implementation.
## Solution
This PR adds the missing `Clone` impl.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The `tracing-tower` crate for compatibility with `tower` is currently
pretty half-baked and incomplete, and doesn't conver a majority of
use-cases.
## Solution
This branch completely rewrites the `tracing-tower` support crate,
hopefully making it more useful.
We now provide a set of `request_span` middleware for instrumenting a
service so that each request passing through it is instrumented with its
own span, and a set of `service_span` metadata that instruments the
entire service with a single span. Additionally, there are now
implementations of `Layer` and `MakeService`, when the `tower-layer` and
`tower-util` crates are also in use. Finally, I've reworked the
`InstrumentableService` extension trait a bit to make it easier to
implement services in different ways, although the old behaviour of
`InstrumentableService::instrument` is unchanged (I've heard
@LucioFranco is using this in prod...).
Most of the functionality of the `tracing-tower-http` crate can now be
reimplemented using the new `tracing-tower` crate (and a feature-flagged
`http` dependency), so that crate should _probably_ now be deprecated.
I've reimplemented its example using `tracing-tower`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
#122 updated all crates to use Rust 2018 syntax, but I neglected to add
`edition = "2018"` to the `Cargo.toml`s.
## Solution
This fixes that.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, there is inconsistent syntax in the `event!` and `span!`
macros when setting explicit parents. The `span!` macro takes both
`target` and `parent` after the level, while `event!` expects `target`
before the level and `parent` after. The `event!` syntax is confusing,
and both macros _should_ use a consistent syntax.
## Solution
This branch updates both macros to follow a consistent syntax where
`target` and `parent` are expected before the level.
Closes#102
* tracing: fix inconsistent syntax in `span!`
Previously, the `span!` macro took the `parent` and `target` attributes
before the level, while the `event!` macro took them after. These macros
should be consistent.
This commit changes the span macro to take these fields before the
level.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* tracing: put `event!` parents before level
The `event!` macro previously took the `parent:` attribute prior to the
level. This seemed confusing, and is inconsistent with the new `span!`
macro syntax.
This commit changes the `event!` macro to match the `span!` macro. It
was also necessary to re-order some match arms so that the macros would
parse correctly.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the "nursery" crates to depend on `tracing` and
`tracing-core` as path dependencies, rather than depending on the
crates.io releases of `tokio-trace` and `tokio-trace-core`. When
`tracing` and `tracing-core` are released, we will change these from
path dependencies to crates.io dependencies.
This branch also updates those crates to track API changes in `tracing`
and `tracing-core`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
See #95
This branch renames everything from `tokio-trace` to `tracing`.
Unlike PR #98, the nursery crates still depend on the crates.io
versions of `tokio-trace` and `tokio-trace-core`, but renamed
to `tracing`/`tracing-core` in `Cargo.toml`. We can update the
nursery crates to depend on local path dependencies in a
subsequent PR, as that will require making code changes to the
nursery crates.
This branch _also_ updates the minimum Rust version to 1.34.0,
to the shock and horror of the millions of `tracing` users still
on Rust 1.26.0. This was necessary in order to allow renaming
crates in `Cargo.toml`, and to resolve that not using the `dyn`
keyword is now a warning on nightly.
Closes#98Closes#95
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
