@jonhoo recorded a great resource about the crate's inner
workings and included practical suggestions about patterns
to follow when annotating one's code.
I added the link to the YouTube video under the "Talks" header
as that seemed appropriate enough.
As part of upgrading syn to 2.0 (e.g.,
https://github.com/tokio-rs/tracing/pull/2516), we need to bump the MSRV
to 1.56. As part of this PR, I've:
- Updated the text descriptions of what would be an in-policy MSRV bump
to use more recent versions of rustc. The _niceness_ of said version
numbers are purely coincidental.
- I've removed some of the exceptions made in CI.yml in order to support
some crates with a higher MSRV.
This PR removes tracing-opentelemetry to a dedicated repo located at
https://github.com/tokio-rs/tracing-opentelemetry. (Note that at time of
writing this PR, the new repo has not be made public). We're moving
tracing-opentelemetry to a dedicated repository for the following
reasons:
1. opentelemetry's MSRV is higher than that of `tracing`'s.
2. more importantly, the main `tracing` repo is getting a bit unweildy
and it feels unreasonable to maintain backports for crates that
integrate with the larger tracing ecosystem.
(https://github.com/tokio-rs/tracing-opentelemetry does not have the
examples present in this repo; this will occur in a PR that will be
linked from _this_ PR.)
Fixes#2280
## Motivation
I've implemented an alternative to [`tracing-wasm`] to fix some issues
that I had when using it (most are open as longer time bug reports, no
need to recount them here). It should be more up to date with the
current tracing framework and, being layer based, is easier to compose
with other subscribers, e.g. supports formatting and timing on event
logs out of the box.
## Solution
Add the [`tracing-web`] crate to the list of related crates.
[`tracing-wasm`]: (https://github.com/storyai/tracing-wasm)
[`tracing-web`]: https://crates.io/crates/tracing-web/
`tracing-subscriber` has been on `0.3` for almost a year now.
I naively copied the versions from the README, and when trying to use
the library with the current versions of e.g. `tracing-opentelemetry`, I
ran into the same error message as seen in this issue:
https://github.com/tokio-rs/tracing/issues/852
Co-authored-by: Bryan Garza <1396101+bryangarza@users.noreply.github.com>
## Motivation
This PR adds [`tracing-forest`](https://crates.io/crates/tracing-forest)
to the list of related crates. `tracing-forest` provides contextual
coherence when writing logs, and is being used by projects like
[Kanidm](https://github.com/kanidm/kanidm/).
## Solution
I added it to the documentation in `lib.rs` and in the README. Am I
missing anything else?
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.
Currently, the documentation states in a few places that the
`tracing-futures` crate is required for asynchronous code to use
`tracing`. This is no longer the case, as `tracing` provides the
`Instrument` combinator for futures; `tracing-futures` is only needed
for things defined in the `futures` crate, such as `Stream` and `Sink`.
This branch updates the documentation so that it doesn't incorrectly
state that `tracing-futures` is required.
## Motivation
As a new user, I stumbled over a broken link and thought I'd fix it.
Also noticed an unrelated open issue while searching for one about the
broken link, and thought I'd fix that too.
## Solution
Fix the typos.
The test-env-log crate has been renamed to test-log to better reflect
its intent of not only catering to env_logger specific initialization
but also tracing (and potentially others in the future).
This change updates the documentation to reference test-log instead of
the now deprecated test-env-log.
## 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>
This PR renames the following:
- `tracing_core::Subscriber` to `tracing_core::Collect`
- `tracing_subscriber::layer::Layer` to `tracing_subscriber::layer::Subscribe`
Authored-by: David Barsksy <dbarsky@amazon.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## 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 😆https://github.com/rust-lang/rust-clippy/issues/6089
## Motivation
tracing-tracy has become tested enough that I’m comfortable with suggesting it to
people at least to try out.
## Solution
List the crate among other related crates.
Includes a listing of `diesel-tracing` as a related third party crate.
This crate provides instrumented versions of the Diesel Connection
structs that will also collect and report information about the
underlying connection.
## Motivation
`diesel-tracing` is a third party integration that provides
instrumentation for diesel connections which may be useful to some
`tracing` users.
https://github.com/CQCL/diesel-tracing/issues/7
## Solution
Adds `diesel-tracing` to the documentation so that users might discover
it.
This PR adds [`tracing-unwrap`](https://docs.rs/tracing-unwrap) to the
list of related crates in the readme.
`tracing-unwrap` provides convenience methods to unwrap `Result` and
`Option` types and automatically report failures via `tracing` before
panicking.
Feel free to edit the description I wrote as you see fit. Thanks!
The test-env-log crate comes in useful when testing tracing based
applications/libraries. With this change we mention it in the Related
Crates section of the README in the root directory and the tracing crate
itself.
## Motivation
PR #934 fixed a bug in the CI configuration where MSRV checks were not
being run correctly. After this was fixed, it was necessary to bump the
MSRV to 1.40.0, as the tests were no longer actually passing on 1.39,
because some dependencies no longer support it.
While updating the documentation to indicate that the new MSRV is 1.40,
I noticed that the note on the MSRV was located inconsistently in the
READMEs and `lib.rs` documentation of various crates, and missing
entirely in some cases. Additionally, there have been some questions on
what our MSRV _policies_ are, and whether MSRV bumps are considered
breaking changes (see e.g. #936).
## Solution
I've updated all the MSRV notes in the documentation and READMEs to
indicate that the MSRV is 1.40. I've also ensured that the MSRV note is
in the same place for every crate (at the end of the "Overview" section
in the docs), and that it's formatted consistently.
Furthermore, I added a new section to the READMEs and `lib.rs` docs
explaining the current MSRV policy in some detail. Hopefully, this
should answer questions like #936 in the future. The MSRV note in the
overview section includes a link to the section with further details.
Finally, while doing this, I noticed a couple of crates
(`tracing-journald` and `tracing-serde`) were missing top-level `lib.rs`
docs. Rather than just adding an MSRV note and nothing else, I went
ahead and fixed this using documentation from those crate's READMEs.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This puts the splash SVG in every crate's README, so
that it will be rendered on crates.io.
I also changed the link to an absolute URL, to ensure that
it works even outside of the repo.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch adds an SVG splash graphic to the main
repository readme, based on the illustration on tokio.rs.
I thought about sticking a big "As seen in rustc!" on there,
and we *could* still do this...
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
