fix: level! macros with constant field names in the first position#2883
Merged
hawkw merged 3 commits intotokio-rs:masterfrom Mar 1, 2024
Merged
fix: level! macros with constant field names in the first position#2883hawkw merged 3 commits intotokio-rs:masterfrom
level! macros with constant field names in the first position#2883hawkw merged 3 commits intotokio-rs:masterfrom
Conversation
hawkw
approved these changes
Mar 1, 2024
Member
hawkw
left a comment
There was a problem hiding this comment.
Thanks for fixing this! This looks good to me!
Contributor
Author
|
@hawkw This (commit 908cc43 after squashing and merging into master) should also be cherry-picked onto If so I can also try and change the PR template so that it's always clear which branches a PR should apply for and future contributors now to base things on master even if a patch is also needed on the |
dpc
pushed a commit
to dpc/tracing
that referenced
this pull request
Apr 20, 2024
…tion (tokio-rs#2883) ## Motivation Const argumetns in `level!` macros do not work when in the first position. This also seems to have fixed tokio-rs#2748 where literals for fields names like `info!("foo" = 2)` could not be used outside the `event!` macro. Fixes tokio-rs#2837 Fixes tokio-rs#2738 ## Solution Previsously, `level!($(args:tt))` was forwarded to `event!(target: ..., level: ..., { $(args:tt) })` but the added curly braces seem to have prevented the `event` macro from correctly understanding the arguments and it tried to pass them to `format!`. With this change there may have some performance impact when expanding the macros in most cases where the braces could have been added as it will take one more step. These are the two relevant `event!` blocks I believe, the new tests used to expand to the first one (with empty fields), now they expand to the latter: ``` (target: $target:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => ( $crate::event!( target: $target, $lvl, { message = $crate::__macro_support::format_args!($($arg)+), $($fields)* } ) ); (target: $target:expr, $lvl:expr, $($arg:tt)+ ) => ( $crate::event!(target: $target, $lvl, { $($arg)+ }) ); ```
20 tasks
hds
pushed a commit
that referenced
this pull request
Nov 21, 2024
…tion (#2883) ## Motivation Const argumetns in `level!` macros do not work when in the first position. This also seems to have fixed #2748 where literals for fields names like `info!("foo" = 2)` could not be used outside the `event!` macro. Fixes #2837 Fixes #2738 ## Solution Previsously, `level!($(args:tt))` was forwarded to `event!(target: ..., level: ..., { $(args:tt) })` but the added curly braces seem to have prevented the `event` macro from correctly understanding the arguments and it tried to pass them to `format!`. With this change there may have some performance impact when expanding the macros in most cases where the braces could have been added as it will take one more step. These are the two relevant `event!` blocks I believe, the new tests used to expand to the first one (with empty fields), now they expand to the latter: ``` (target: $target:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => ( $crate::event!( target: $target, $lvl, { message = $crate::__macro_support::format_args!($($arg)+), $($fields)* } ) ); (target: $target:expr, $lvl:expr, $($arg:tt)+ ) => ( $crate::event!(target: $target, $lvl, { $($arg)+ }) ); ```
hds
pushed a commit
that referenced
this pull request
Nov 22, 2024
…tion (#2883) ## Motivation Const argumetns in `level!` macros do not work when in the first position. This also seems to have fixed #2748 where literals for fields names like `info!("foo" = 2)` could not be used outside the `event!` macro. Fixes #2837 Fixes #2738 ## Solution Previsously, `level!($(args:tt))` was forwarded to `event!(target: ..., level: ..., { $(args:tt) })` but the added curly braces seem to have prevented the `event` macro from correctly understanding the arguments and it tried to pass them to `format!`. With this change there may have some performance impact when expanding the macros in most cases where the braces could have been added as it will take one more step. These are the two relevant `event!` blocks I believe, the new tests used to expand to the first one (with empty fields), now they expand to the latter: ``` (target: $target:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => ( $crate::event!( target: $target, $lvl, { message = $crate::__macro_support::format_args!($($arg)+), $($fields)* } ) ); (target: $target:expr, $lvl:expr, $($arg:tt)+ ) => ( $crate::event!(target: $target, $lvl, { $($arg)+ }) ); ```
hds
added a commit
that referenced
this pull request
Nov 27, 2024
# 0.1.41 (November 25, 2024) [[[crates.io][crate-0.1.41]]] | [[[docs.rs][docs-0.1.41]]] This release updates the `tracing-core` dependency to [v0.1.33][core-0.1.33] and the `tracing-attributes` dependency to [v0.1.28][attrs-0.1.28]. ### Added - **core**: Add index API for `Field` ([#2820]) - **core**: Allow `&[u8]` to be recorded as event/span field ([#2954]) ### Changed - Bump MSRV to 1.63 ([#2793]) - **core**: Use const `thread_local`s when possible ([#2838]) ### Fixed - Removed core imports in macros ([#2762]) - **attributes**: Added missing RecordTypes for instrument ([#2781]) - **attributes**: Change order of async and unsafe modifier ([#2864]) - Fix missing field prefixes ([#2878]) - **attributes**: Extract match scrutinee ([#2880]) - Fix non-simple macro usage without message ([#2879]) - Fix event macros with constant field names in the first position ([#2883]) - Allow field path segments to be keywords ([#2925]) - **core**: Fix missed `register_callsite` error ([#2938]) - **attributes**: Support const values for `target` and `name` ([#2941]) - Prefix macro calls with ::core to avoid clashing with local macros ([#3024]) [#2762]: #2762 [#2781]: #2781 [#2793]: #2793 [#2820]: #2820 [#2838]: #2838 [#2864]: #2864 [#2878]: #2878 [#2879]: #2879 [#2880]: #2880 [#2883]: #2883 [#2925]: #2925 [#2938]: #2938 [#2941]: #2941 [#2954]: #2954 [#3024]: #3024 [attrs-0.1.28]: https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.28 [core-0.1.33]: https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.33 [docs-0.1.41]: https://docs.rs/tracing/0.1.41/tracing/ [crate-0.1.41]: https://crates.io/crates/tracing/0.1.41
hds
added a commit
that referenced
this pull request
Nov 27, 2024
# 0.1.41 (November 25, 2024) [[[crates.io][crate-0.1.41]]] | [[[docs.rs][docs-0.1.41]]] This release updates the `tracing-core` dependency to [v0.1.33][core-0.1.33] and the `tracing-attributes` dependency to [v0.1.28][attrs-0.1.28]. ### Added - **core**: Add index API for `Field` ([#2820]) - **core**: Allow `&[u8]` to be recorded as event/span field ([#2954]) ### Changed - Bump MSRV to 1.63 ([#2793]) - **core**: Use const `thread_local`s when possible ([#2838]) ### Fixed - Removed core imports in macros ([#2762]) - **attributes**: Added missing RecordTypes for instrument ([#2781]) - **attributes**: Change order of async and unsafe modifier ([#2864]) - Fix missing field prefixes ([#2878]) - **attributes**: Extract match scrutinee ([#2880]) - Fix non-simple macro usage without message ([#2879]) - Fix event macros with constant field names in the first position ([#2883]) - Allow field path segments to be keywords ([#2925]) - **core**: Fix missed `register_callsite` error ([#2938]) - **attributes**: Support const values for `target` and `name` ([#2941]) - Prefix macro calls with ::core to avoid clashing with local macros ([#3024]) [#2762]: #2762 [#2781]: #2781 [#2793]: #2793 [#2820]: #2820 [#2838]: #2838 [#2864]: #2864 [#2878]: #2878 [#2879]: #2879 [#2880]: #2880 [#2883]: #2883 [#2925]: #2925 [#2938]: #2938 [#2941]: #2941 [#2954]: #2954 [#3024]: #3024 [attrs-0.1.28]: https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.28 [core-0.1.33]: https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.33 [docs-0.1.41]: https://docs.rs/tracing/0.1.41/tracing/ [crate-0.1.41]: https://crates.io/crates/tracing/0.1.41
hds
added a commit
that referenced
this pull request
Nov 27, 2024
# 0.1.41 (November 25, 2024) [[[crates.io][crate-0.1.41]]] | [[[docs.rs][docs-0.1.41]]] This release updates the `tracing-core` dependency to [v0.1.33][core-0.1.33] and the `tracing-attributes` dependency to [v0.1.28][attrs-0.1.28]. ### Added - **core**: Add index API for `Field` ([#2820]) - **core**: Allow `&[u8]` to be recorded as event/span field ([#2954]) ### Changed - Bump MSRV to 1.63 ([#2793]) - **core**: Use const `thread_local`s when possible ([#2838]) ### Fixed - Removed core imports in macros ([#2762]) - **attributes**: Added missing RecordTypes for instrument ([#2781]) - **attributes**: Change order of async and unsafe modifier ([#2864]) - Fix missing field prefixes ([#2878]) - **attributes**: Extract match scrutinee ([#2880]) - Fix non-simple macro usage without message ([#2879]) - Fix event macros with constant field names in the first position ([#2883]) - Allow field path segments to be keywords ([#2925]) - **core**: Fix missed `register_callsite` error ([#2938]) - **attributes**: Support const values for `target` and `name` ([#2941]) - Prefix macro calls with ::core to avoid clashing with local macros ([#3024]) [#2762]: #2762 [#2781]: #2781 [#2793]: #2793 [#2820]: #2820 [#2838]: #2838 [#2864]: #2864 [#2878]: #2878 [#2879]: #2879 [#2880]: #2880 [#2883]: #2883 [#2925]: #2925 [#2938]: #2938 [#2941]: #2941 [#2954]: #2954 [#3024]: #3024 [attrs-0.1.28]: https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.28 [core-0.1.33]: https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.33 [docs-0.1.41]: https://docs.rs/tracing/0.1.41/tracing/ [crate-0.1.41]: https://crates.io/crates/tracing/0.1.41
hds
added a commit
that referenced
this pull request
Nov 27, 2024
# 0.1.41 (November 25, 2024) [ [crates.io][crate-0.1.41] ] | [ [docs.rs][docs-0.1.41] ] This release updates the `tracing-core` dependency to [v0.1.33][core-0.1.33] and the `tracing-attributes` dependency to [v0.1.28][attrs-0.1.28]. ### Added - **core**: Add index API for `Field` ([#2820]) - **core**: Allow `&[u8]` to be recorded as event/span field ([#2954]) ### Changed - Bump MSRV to 1.63 ([#2793]) - **core**: Use const `thread_local`s when possible ([#2838]) ### Fixed - Removed core imports in macros ([#2762]) - **attributes**: Added missing RecordTypes for instrument ([#2781]) - **attributes**: Change order of async and unsafe modifier ([#2864]) - Fix missing field prefixes ([#2878]) - **attributes**: Extract match scrutinee ([#2880]) - Fix non-simple macro usage without message ([#2879]) - Fix event macros with constant field names in the first position ([#2883]) - Allow field path segments to be keywords ([#2925]) - **core**: Fix missed `register_callsite` error ([#2938]) - **attributes**: Support const values for `target` and `name` ([#2941]) - Prefix macro calls with ::core to avoid clashing with local macros ([#3024]) [#2762]: #2762 [#2781]: #2781 [#2793]: #2793 [#2820]: #2820 [#2838]: #2838 [#2864]: #2864 [#2878]: #2878 [#2879]: #2879 [#2880]: #2880 [#2883]: #2883 [#2925]: #2925 [#2938]: #2938 [#2941]: #2941 [#2954]: #2954 [#3024]: #3024 [attrs-0.1.28]: https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.28 [core-0.1.33]: https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.33 [docs-0.1.41]: https://docs.rs/tracing/0.1.41/tracing/ [crate-0.1.41]: https://crates.io/crates/tracing/0.1.41
hds
added a commit
that referenced
this pull request
Nov 27, 2024
# 0.1.41 (November 25, 2024) [ [crates.io][crate-0.1.41] ] | [ [docs.rs][docs-0.1.41] ] This release updates the `tracing-core` dependency to [v0.1.33][core-0.1.33] and the `tracing-attributes` dependency to [v0.1.28][attrs-0.1.28]. ### Added - **core**: Add index API for `Field` ([#2820]) - **core**: Allow `&[u8]` to be recorded as event/span field ([#2954]) ### Changed - Bump MSRV to 1.63 ([#2793]) - **core**: Use const `thread_local`s when possible ([#2838]) ### Fixed - Removed core imports in macros ([#2762]) - **attributes**: Added missing RecordTypes for instrument ([#2781]) - **attributes**: Change order of async and unsafe modifier ([#2864]) - Fix missing field prefixes ([#2878]) - **attributes**: Extract match scrutinee ([#2880]) - Fix non-simple macro usage without message ([#2879]) - Fix event macros with constant field names in the first position ([#2883]) - Allow field path segments to be keywords ([#2925]) - **core**: Fix missed `register_callsite` error ([#2938]) - **attributes**: Support const values for `target` and `name` ([#2941]) - Prefix macro calls with ::core to avoid clashing with local macros ([#3024]) [#2762]: #2762 [#2781]: #2781 [#2793]: #2793 [#2820]: #2820 [#2838]: #2838 [#2864]: #2864 [#2878]: #2878 [#2879]: #2879 [#2880]: #2880 [#2883]: #2883 [#2925]: #2925 [#2938]: #2938 [#2941]: #2941 [#2954]: #2954 [#3024]: #3024 [attrs-0.1.28]: https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.28 [core-0.1.33]: https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.33 [docs-0.1.41]: https://docs.rs/tracing/0.1.41/tracing/ [crate-0.1.41]: https://crates.io/crates/tracing/0.1.41
hds
added a commit
that referenced
this pull request
Nov 27, 2024
# 0.1.41 (November 27, 2024) [ [crates.io][crate-0.1.41] ] | [ [docs.rs][docs-0.1.41] ] This release updates the `tracing-core` dependency to [v0.1.33][core-0.1.33] and the `tracing-attributes` dependency to [v0.1.28][attrs-0.1.28]. ### Added - **core**: Add index API for `Field` ([#2820]) - **core**: Allow `&[u8]` to be recorded as event/span field ([#2954]) ### Changed - Bump MSRV to 1.63 ([#2793]) - **core**: Use const `thread_local`s when possible ([#2838]) ### Fixed - Removed core imports in macros ([#2762]) - **attributes**: Added missing RecordTypes for instrument ([#2781]) - **attributes**: Change order of async and unsafe modifier ([#2864]) - Fix missing field prefixes ([#2878]) - **attributes**: Extract match scrutinee ([#2880]) - Fix non-simple macro usage without message ([#2879]) - Fix event macros with constant field names in the first position ([#2883]) - Allow field path segments to be keywords ([#2925]) - **core**: Fix missed `register_callsite` error ([#2938]) - **attributes**: Support const values for `target` and `name` ([#2941]) - Prefix macro calls with ::core to avoid clashing with local macros ([#3024]) [#2762]: #2762 [#2781]: #2781 [#2793]: #2793 [#2820]: #2820 [#2838]: #2838 [#2864]: #2864 [#2878]: #2878 [#2879]: #2879 [#2880]: #2880 [#2883]: #2883 [#2925]: #2925 [#2938]: #2938 [#2941]: #2941 [#2954]: #2954 [#3024]: #3024 [attrs-0.1.28]: https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.28 [core-0.1.33]: https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.33 [docs-0.1.41]: https://docs.rs/tracing/0.1.41/tracing/ [crate-0.1.41]: https://crates.io/crates/tracing/0.1.41
hds
added a commit
that referenced
this pull request
Nov 27, 2024
# 0.1.41 (November 27, 2024) [ [crates.io][crate-0.1.41] ] | [ [docs.rs][docs-0.1.41] ] This release updates the `tracing-core` dependency to [v0.1.33][core-0.1.33] and the `tracing-attributes` dependency to [v0.1.28][attrs-0.1.28]. ### Added - **core**: Add index API for `Field` ([#2820]) - **core**: Allow `&[u8]` to be recorded as event/span field ([#2954]) ### Changed - Bump MSRV to 1.63 ([#2793]) - **core**: Use const `thread_local`s when possible ([#2838]) ### Fixed - Removed core imports in macros ([#2762]) - **attributes**: Added missing RecordTypes for instrument ([#2781]) - **attributes**: Change order of async and unsafe modifier ([#2864]) - Fix missing field prefixes ([#2878]) - **attributes**: Extract match scrutinee ([#2880]) - Fix non-simple macro usage without message ([#2879]) - Fix event macros with constant field names in the first position ([#2883]) - Allow field path segments to be keywords ([#2925]) - **core**: Fix missed `register_callsite` error ([#2938]) - **attributes**: Support const values for `target` and `name` ([#2941]) - Prefix macro calls with ::core to avoid clashing with local macros ([#3024]) [#2762]: #2762 [#2781]: #2781 [#2793]: #2793 [#2820]: #2820 [#2838]: #2838 [#2864]: #2864 [#2878]: #2878 [#2879]: #2879 [#2880]: #2880 [#2883]: #2883 [#2925]: #2925 [#2938]: #2938 [#2941]: #2941 [#2954]: #2954 [#3024]: #3024 [attrs-0.1.28]: https://github.com/tokio-rs/tracing/releases/tag/tracing-attributes-0.1.28 [core-0.1.33]: https://github.com/tokio-rs/tracing/releases/tag/tracing-core-0.1.33 [docs-0.1.41]: https://docs.rs/tracing/0.1.41/tracing/ [crate-0.1.41]: https://crates.io/crates/tracing/0.1.41
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. The test files are generated (no need to check them in) and then validated by `cargo check` on CI. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives).
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. The test files are generated (no need to check them in) and then validated by `cargo check` on CI. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives).
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. The test files are generated (no need to check them in) and then validated by `cargo check` on CI. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives).
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. The test files are generated (no need to check them in) and then validated by `cargo check` on CI. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives).
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. The test files are generated (no need to check them in) and then validated by `cargo check` on CI. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives).
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives). The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives). The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives). The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives). The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. When run against the unmodified macros in `tracing`, there were 504 `info!` macro invocations which failed to compile, out of a total of 9760 (including all combinations of directives). The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). Some recent examples from #3407 is the following that doesn't work: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does work: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also work: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. For each macro, there are 9760 invocations generated (including all combinatiosn of directives). When run against the current `tracing` macros, this resulted in the following failure counts: * `event!`: 705 * `info!`, `warn!`: 1683 (each) * `trace!`, `debug!`, `error!`: 1652 (each) The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). A recent example from #3407 is the following invocation that doesn't compile: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does compile: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also compile: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. For each macro, there are 9760 invocations generated (including all combinatiosn of directives). When run against the current `tracing` macros, this resulted in the following failure counts: * `event!`: 705 * `info!`, `warn!`: 1683 (each) * `trace!`, `debug!`, `error!`: 1652 (each) The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 17, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). A recent example from #3407 is the following invocation that doesn't compile: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does compile: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also compile: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. For each macro, there are 9760 invocations generated (including all combinatiosn of directives). When run against the current `tracing` macros, this resulted in the following failure counts: * `event!`: 705 * `info!`, `warn!`: 1683 (each) * `trace!`, `debug!`, `error!`: 1652 (each) The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 18, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). A recent example from #3407 is the following invocation that doesn't compile: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does compile: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also compile: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. For each macro, there are 9760 invocations generated (including all combinatiosn of directives). When run against the current `tracing` macros, this resulted in the following failure counts: * `event!`: 705 * `info!`, `warn!`: 1683 (each) * `trace!`, `debug!`, `error!`: 1652 (each) The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
hds
added a commit
that referenced
this pull request
Dec 18, 2025
There are a large number of combinations of field types which currently are not matched by the level event macros (e.g. `info!`). A recent example from #3407 is the following invocation that doesn't compile: ```rust info!(name: "order.received.ok", order.id = 123, "order received"); ``` However, the corresponding `event!` macro does compile: ```rust event!(name: "order.received.ok", Level::INFO, order.id = 123, "order received"); ``` And other variants also compile: ```rust // Without `name:` directive info!(order.id = 123, "order received"); // With another field before the dotted one info!(name: "order.received.ok", foo = true, order.id = 123, "order received"); ``` Many such cases have been fixed in the past (#2983, #2883, #2879). However, this has been a bit like wack-a-mole, where we keep finding issues and then fixing those issues, adding extra tests for them and then going on our way. Since the complexity is often in combinations (as above, only when using the `name:` directive together with a dotted field name on the first field), it would be useful to have some extensive tests that attempt to cover all possible combinations. It turns out that there are **a lot** of combiantions. This change adds an `xtask` that generates tests for event macros (span macros are out of scope for this change) similar to the ones found in `tracing/tests/macros.rs`. Which is to say, tests containing macros which should compile, but don't need to run. Owing to the large number of combinations, the tests are split into test files by macro (e.g. `event!`, `info!`) and directive combination (e.g. no directives, just `name:`, `name:` and `target:`). The tests are kept in a separate crate outside the main workspace to avoid rust-analyzer trying to parse the files - as they are quite large. Specifically, there are 1220 macro invocations per test file. For each macro, there are 9760 invocations generated (including all combinatiosn of directives). When run against the current `tracing` macros, this resulted in the following failure counts: * `event!`: 705 * `info!`, `warn!`: 1683 (each) * `trace!`, `debug!`, `error!`: 1652 (each) The test files are generated (no need to check them in) and then validated by `cargo check` on CI. The CI job has not been made blocking because none of the errors have been fixed yet!
This file contains hidden or 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
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.
Motivation
#2837
Const argumetns in
level!macros do not work when in the first positoin.This also seems to have fixed #2748 where literals for fields names like
info!("foo" = 2)could not be used outside theevent!macro.Solution
Previsously,
level!($(args:tt))was forwarded toevent!(target: ..., level: ..., { $(args:tt) })but the added curly braces seem to have prevented theeventmacro from correctly understanding the arguments and it tried to pass them toformat!.With this change there may have some performance impact when expanding the macros in most cases where the braces could have been added as it will take one more step.
These are the two relevant
event!blocks I believe, the new tests used to expand to the first one (with empty fields), now they expand to the latter: