tracing: Replace macro-rules with procedural macros

[hawkw]

Feature Request

Crates

tracing

Motivation

Now that we are not supporting Rust 1.26.0 as our minimum compatible version, we can ship procedural macros in tracing. Replacing the existing macro_rules macros should improve user-facing error messages, make the macros more maintainable, and make it easier to add new features to them in the future (such as #83).

Proposal

The macros should be in a separate crate, but they should be re-exported by tracing. We should re-implement the existing macro syntax prior to adding any new features, and do that separately as a follow-up.

I think the new macros could live in the existingtracing-proc-macros or tracing-macros crates. Perhaps we should use tracing-macros and move everything currently in tracing-proc-macros there (and rewrite or remove the macros currently in tracing-macros, which are very experimental).

[hawkw]

I believe @Ralith is working on this. My understanding is that it is currently blocked on dtolnay/syn#661.

[Ralith]

I believe @Ralith is working on this. My understanding is that it is currently blocked on dtolnay/syn#661.

This is accurate. If that issue can be fixed, I am otherwise very close to a working prototype of event!().

I think the new macros could live in the existingtracing-proc-macros or tracing-macros crates. Perhaps we should use tracing-macros and move everything currently in tracing-proc-macros there (and rewrite or remove the macros currently in tracing-macros, which are very experimental).

These macros will necessarily rely on proc-macro-hack, which means that they can't be used by downstream code directly from the crate they're implemented in; an intermediate re-exporting crate is always necessary. My understanding is that tokio(-proc)-macros are intended to be user-facing, so we'll still need an internal -impl crate.

[Ralith]

Looks like it might not be a syn issue: dtolnay/proc-macro-hack#34

[Ralith]

Now isolated to a compiler issue: rust-lang/rust#62325

[hawkw]

Thanks for keeping us updated, @Ralith --- great to hear that progress is being made on unblocking this!

[hawkw]

Looks like the compiler bug has been fixed in rust-lang/rust#62393, so hopefully we can move forwards with this once the fix is on stable.