chore: Backports to v0.1.x #2298

This fixes new Clippy lints introduced in the latest Rust version. * chore: fix `clippy::borrow_deref_ref` lints * chore: fix `clippy::partial_eq_without_eq` lint

`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: #852 Co-authored-by: Bryan Garza <1396101+bryangarza@users.noreply.github.com>

Co-authored-by: Bryan Garza <1396101+bryangarza@users.noreply.github.com>

## Motivation Return type errors on instrumented async functions are a bit vague, since the type error originates within the macro itself due to the indirection of additional `async {}` blocks generated in the proc-macro (and due to the way that inference propagates around in Rust). This leads to a pretty difficult to understand error. For example: ```rust #[instrument] async fn foo() -> String { "" } ``` results in... ``` error[E0308]: mismatched types --> src/main.rs:1:1 | 1 | #[tracing::instrument] | ^^^^^^^^^^^^^^^^^^^^^^- help: try using a conversion method: `.to_string()` | | | expected struct `String`, found `&str` ``` ## Solution Installs a fake `return` statement as the first thing that happens in the auto-generated block of an instrumented async function. This causes the coercion machinery within rustc to infer the right return type (matching the the outer function) eagerly, as opposed to after the `async {}` block has been type-checked. This will cause us to both be able to point out the return type span correctly, and properly suggest fixes on the expressions that cause the type mismatch. After this change, the example code above compiles to: ``` error[E0308]: mismatched types --> src/main.rs:3:5 | 3 | "" | ^^- help: try using a conversion method: `.to_string()` | | | expected struct `String`, found `&str` | note: return type inferred to be `String` here --> src/main.rs:2:20 | 2 | async fn foo() -> String { | ^^^^^^ ```

I just saw this warning when trying to debug something in Miri: ``` warning: some trace filter directives would enable traces that are disabled statically | `miri::tls=trace` would enable the TRACE level for the `miri::tls` target = note: the static max level is `info` = help: to enable DEBUG logging, remove the `max_level_info` feature ``` I spent 10min figuring out why the `log` crate is doing this (Miri is using env-logger for logging), until I realized that this error actually originates from inside rustc, which I guess uses `tracing`. It would have helped if the error message would say which crate is even talking to me here. :)

The `on_register_dispatch` method is invoked when a `Subscriber` is registered as a `Dispatch`. This method should be overridden to perform actions upon the installation of a subscriber/layer; for instance, to send a copy of the subscriber's `Dispatch` to a worker thread.

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/

…#2296) One can want to have an event added from outside context of a span, especially in an async code (e.g. between polls of the future, or between polling multiple futures instrumented with that span). Then it is expected that the event will be attached indeed to the span specified as the parent and not the contextual one. Fixes: #2295 See #2295

## Motivation Support the latest OpenTelemetry specification. ## Solution Update `opentelemetry` to the latest `0.18.x` release. Breaking changes in the metrics spec have removed value recorders and added histograms so the metrics layer's `value.` prefix has been changed to `histogram.` and behaves accordingly. Additionally the `PushController` configuration for the metrics layer has been simplified to accept a `BasicController` that can act in either push or pull modes. Finally trace sampling in the sdk's `PreSampledTracer` impl has been updated to match the sampling logic in open-telemetry/opentelemetry-rust#839. * Update MSRV to 1.56 * Update examples * Fix async-trait dep * Update msrv action Co-authored-by: Eliza Weisman <eliza@buoyant.io>

…#2308) ## Motivation `bare_trait_objects` lint will become a hard error in Rust 2021. While tracing is still using Rust 2018, `bare_trait_objects` is a warning in the MSRV and `dyn` keyword is recommended. ## Solution Replace all `&Value` with `&dyn Value` in macro expansions.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore: Backports to v0.1.x #2298

chore: Backports to v0.1.x #2298

Commits on Sep 19, 2022