You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the span_telemetry macro has "unknown" hard-coded for the caller's name as tracing::span!() requires name to be const. This requirement is because internally tracing::span!() is evaluating name in static context however coercing the call site outside of #[proc_macro_attribute] (like how #[tracing::instrument] is implemented) has been impossible (I've tried everything and then some).
This issue is to track the possibility of either tracing::span() relaxing their requirement for static context, or somehow get the following compiling with the same meaning:
Since we already have the caller here, I even tried passing the caller's name to a #[proc_macro] which creates a literal string via a token stream and injects it into it's own call to tracing::span!(), but the compiler could still tell it wasn't const 🙃
The text was updated successfully, but these errors were encountered:
Currently, the
span_telemetry
macro has "unknown" hard-coded for the caller's name astracing::span!()
requiresname
to beconst
. This requirement is because internallytracing::span!()
is evaluatingname
instatic
context however coercing the call site outside of#[proc_macro_attribute]
(like how#[tracing::instrument]
is implemented) has been impossible (I've tried everything and then some).This issue is to track the possibility of either
tracing::span()
relaxing their requirement forstatic
context, or somehow get the following compiling with the same meaning:Since we already have the caller here, I even tried passing the caller's name to a
#[proc_macro]
which creates a literal string via a token stream and injects it into it's own call totracing::span!()
, but the compiler could still tell it wasn'tconst
🙃The text was updated successfully, but these errors were encountered: