mirror of
https://github.com/tokio-rs/tracing.git
synced 2025-10-02 07:20:35 +00:00
ffca615cc5
## Motivation:
The upgrade from Rust 1.36.0 to Rust 1.37.0 introduced a regression in
`tracing-log` on macOS, where callsite identifiers for generated `log`
callsites that were previously considered equal are no longer equal.
## Solution:
Previously, the generated callsite was represented as a zero-sized
struct with no fields:
```rust
struct Callsite;
```
The metadata for the generated callsite was constructed by invoking the
`identifiy_callsite!` macro with `&Callsite`, like this:
```rust
field::FieldSet::new(FIELD_NAMES, identify_callsite!(&Callsite)),
```
and the block generated by the macro ended with `&Callsite`, which would
be assigned to a static.
Previously, this resulted with the callsite identifier and the static
being pointers to the _same_ address, and everything worked correctly.
However, the compiler behaviour appears to have changed in Rust
1.37.0, and two &-references to the same zero-sized struct are, at least
on macOS, no longer pointers to the same memory address.
This commit fixes the regression by changing the `log_cs!` macro to
create a `static` and assign the zero-sized struct to it, like this:
```rust
static CALLSITE: Callsite = Callsite;
```
and use references to the _static_ rather than to the type constructor.
Now, references to `&CALLSITE` point to the same memory address, even on
macOS.
I've also made some minor tweaks to the tests that caught this to make
debugging future log callsite bugs easier. Now, rather than one test
function that tests all log levels, we create a separate test for each
level, to make it easier to determine whether there's a bug for all log
callsites or only a particular one. Also, I've added more information
to the assertion failure messages in these tests.
## Notes:
This may have been our fault. I'm not sure if the behaviour of
references to a new instance of a zero-sized struct (i.e. `&Callsite`)
were ever _guaranteed_ to point to the same memory location or not, so
it may be totally fine of the compiler to change this on us without
warning. However, if this is guaranteed, this is a compiler bug.
I think that by switching to using a static, however, we are making the
guarantee more explicit in either case: if the compiler were ever to
compile two references to the same static as references to different
addresses, that would be a violation of the guarantees of the `static`
keyword. Note that [The Rust Reference][1] states that:
> All references to the static refer to the same memory location.
[1]: https://doc.rust-lang.org/reference/items/static-items.html#static-items
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
tracing-log
Warning: Until tracing-log has a 0.1.0 release on crates.io, please treat every release as potentially breaking.
log compatibility for tracing.
Overview
tracing is a framework for instrumenting Rust programs with context-aware,
structured, event-based diagnostic information. This crate provides
compatibility layers for using tracing alongside the logging facade provided
by the log crate.
This crate provides:
LogTracer, alog::Logimplementation that consumeslog::Records and outputs them astracing::Event.TraceLogger, atracing::Subscriberimplementation that consumestracing::Events and outputslog::Record, allowing an existing logger implementation to be used to record trace events.
License
This project is licensed under the MIT license.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Tracing by you, shall be licensed as MIT, without any additional terms or conditions.