chore: Backports to v0.1.x #2298
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davidbarsky
requested review from
jtescher,
a team,
yaahc and
hawkw
as code owners
|
looks like there are some surprising if those exist on the main branch as well, we should fix them separately... |
Yeah, they are. I"ll try taking a look tomorrow morning. |
|
@davidbarsky any updates on this? |
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>
hawkw
force-pushed
the
david/v0.1.0-backports
branch
from
c9dec5e
to
bd56070
Compare
|
The reason for the Clippy failures is that PR #2269 wasn't backported correctly, and the We probably should have had a test that |
…#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.
|
sorry, i thought i replied; thanks for catching my mistake there. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some additional backports.
(Let's see if CI passes first—I suspect that it won't...)