-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Uniform enter_trace_span!
and add documentation
#144688
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
8e78616
3b5fec0
e1f674c
bb08a4d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1245,43 +1245,14 @@ impl ToU64 for usize { | |
} | ||
} | ||
|
||
/// This struct is needed to enforce `#[must_use]` on values produced by [enter_trace_span] even | ||
/// when the "tracing" feature is not enabled. | ||
#[must_use] | ||
pub struct MaybeEnteredTraceSpan { | ||
#[cfg(feature = "tracing")] | ||
pub _entered_span: tracing::span::EnteredSpan, | ||
} | ||
|
||
/// Enters a [tracing::info_span] only if the "tracing" feature is enabled, otherwise does nothing. | ||
/// This is like [rustc_const_eval::enter_trace_span] except that it does not depend on the | ||
/// [Machine] trait to check if tracing is enabled, because from the Miri codebase we can directly | ||
/// check whether the "tracing" feature is enabled, unlike from the rustc_const_eval codebase. | ||
/// | ||
/// In addition to the syntax accepted by [tracing::span!], this macro optionally allows passing | ||
/// the span name (i.e. the first macro argument) in the form `NAME::SUBNAME` (without quotes) to | ||
/// indicate that the span has name "NAME" (usually the name of the component) and has an additional | ||
/// more specific name "SUBNAME" (usually the function name). The latter is passed to the [tracing] | ||
/// infrastructure as a span field with the name "NAME". This allows not being distracted by | ||
/// subnames when looking at the trace in <https://ui.perfetto.dev>, but when deeper introspection | ||
/// is needed within a component, it's still possible to view the subnames directly in the UI by | ||
/// selecting a span, clicking on the "NAME" argument on the right, and clicking on "Visualize | ||
/// argument values". | ||
/// ```rust | ||
/// // for example, the first will expand to the second | ||
/// enter_trace_span!(borrow_tracker::on_stack_pop, /* ... */) | ||
/// enter_trace_span!("borrow_tracker", borrow_tracker = "on_stack_pop", /* ... */) | ||
/// ``` | ||
/// This calls [rustc_const_eval::enter_trace_span] with [MiriMachine] as the first argument, which | ||
/// will in turn call [MiriMachine::enter_trace_span], which takes care of determining at compile | ||
/// time whether to trace or not (and supposedly the call is compiled out if tracing is disabled). | ||
/// Look at [rustc_const_eval::enter_trace_span] for complete documentation, examples and tips. | ||
#[macro_export] | ||
macro_rules! enter_trace_span { | ||
($name:ident :: $subname:ident $($tt:tt)*) => {{ | ||
enter_trace_span!(stringify!($name), $name = %stringify!($subname) $($tt)*) | ||
}}; | ||
|
||
($($tt:tt)*) => { | ||
$crate::MaybeEnteredTraceSpan { | ||
#[cfg(feature = "tracing")] | ||
_entered_span: tracing::info_span!($($tt)*).entered() | ||
} | ||
rustc_const_eval::enter_trace_span!($crate::MiriMachine<'static>, $($tt)*) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So... what is your plan now? I thought I had suggested to do this in a future PR, it's anyway easier to evaluate in the miri repo than here. I also didn't realize we'd still need a custom macro... but we can remove the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sorry, I was still writing the other comment ;-)
Yeah sorry about that, fixed now |
||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we duplicate this macro between Miri and rustc? Can we reuse the rustc definition in Miri?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because from Miri we use
#[cfg(feature = "tracing")]
to decide whether to do tracing or not, and fromrustc_const_eval
we instead have to callMachine::enter_trace_span
and let it decide whether to do tracing or not. I guess we could make the Miri macro passMiriMachine<'static>
as$machine
to this macro and then it would work, but#[cfg(feature = "tracing")]
will probably optimize things out better than a call toMachine::enter_trace_span
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... then please add that as a comment in the Miri version of the macro.
It may be worth briefly benchmarking (
./miri bench
, not the option to save/load a baseline file) whether it makes any difference to use the rustc version from Miri -- but that doesn't have to block this PR.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did the benchmarks in the end and it seems like there is no difference (the differences are all within statistical significance, and some are higher some lower). So I pushed a commit that makes the Miri one just call the rustc_const_eval one.
Benchmark of #[cfg(feature = "tracing")]
Benchmark of deferring to rustc_const_eval::enter_trace_span!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you're just too fast, okay. :D
(It's easier to compare these benchmarks if you use
--save-baseline
/--load-baseline
.)