fix Name / parent variant of event!()
#2983
Merged
Conversation
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
kaffarell
approved these changes
Jun 25, 2024
|
Friendly ping: can this be merged in? |
Member
|
Wdyt @hds? This targets the v0.1.x branch, though maybe because it's only relevant for that? May want to cherry-pick onto your backport branch? |
In the case of an event with a name and a parent, the change in tokio-rs#2083 to use a free function instead of a method for `is_enabled` was not applied. This particular variant was also not covered by any tests, which is how this error slipped through CI. This change fixes the `is_enabled` call and adds additional test coverage for this macros case.
hds
pushed a commit
that referenced
this pull request
May 30, 2025
In the case of an event with a name and a parent, the change in #2083 to use a free function instead of a method for `is_enabled` was not applied. This particular variant was also not covered by any tests, which is how this error slipped through CI. This change fixes the `is_enabled` call and adds additional test coverage for this macros case. This change was originally submitted by @Mododo in #2983, but we have an issue where first-time contributor PRs to the `v0.1.x` branch don't trigger CI and we can't trigger it manually, so it needed to be recreated.
Contributor
|
Can't get CI triggered for a first time contributor PR to |
Member
|
It looks like I was able to run the workflows.. Not that it's all that useful now that there's another PR 😅 |
9 tasks
hds
added a commit
that referenced
this pull request
Nov 26, 2025
# 0.1.42 (November 26, 2025) ### Added - **attributes**: Support constant expressions as instrument field names ([#3158]) - Add `record_all!` macro for recording multiple values in one call ([#3227]) - **core**: Improve code generation at trace points significantly ([#3398]) ### Changed - `tracing-core`: updated to 0.1.35 ([#3414]) - `tracing-attributes`: updated to 0.1.31 ([#3417]) ### Fixed - Fix "name / parent" variant of `event!` ([#2983]) - Remove 'r#' prefix from raw identifiers in field names ([#3130]) - Fix perf regression when `release_max_level_*` not set ([#3373]) - Use imported instead of fully qualified path ([#3374]) - Make `valueset` macro sanitary ([#3382]) ### Documented - **core**: Add missing `dyn` keyword in `Visit` documentation code sample ([#3387]) [#2983]: https://github.com/tokio-rs/tracing/pull/#2983 [#3130]: https://github.com/tokio-rs/tracing/pull/#3130 [#3158]: https://github.com/tokio-rs/tracing/pull/#3158 [#3227]: https://github.com/tokio-rs/tracing/pull/#3227 [#3373]: https://github.com/tokio-rs/tracing/pull/#3373 [#3374]: https://github.com/tokio-rs/tracing/pull/#3374 [#3382]: https://github.com/tokio-rs/tracing/pull/#3382 [#3387]: https://github.com/tokio-rs/tracing/pull/#3387 [#3398]: https://github.com/tokio-rs/tracing/pull/#3398 [#3414]: https://github.com/tokio-rs/tracing/pull/#3414 [#3417]: https://github.com/tokio-rs/tracing/pull/#3417
hds
added a commit
that referenced
this pull request
Nov 26, 2025
# 0.1.42 (November 26, 2025) ### Important The [`Span::record_all`] method has been removed from the documented API. It was always unsuable via the documented API as it requried a `ValueSet` which has no publically documented constructors. The method remains, but should not be used outside of `tracing` macros. ### Added - **attributes**: Support constant expressions as instrument field names ([#3158]) - Add `record_all!` macro for recording multiple values in one call ([#3227]) - **core**: Improve code generation at trace points significantly ([#3398]) ### Changed - `tracing-core`: updated to 0.1.35 ([#3414]) - `tracing-attributes`: updated to 0.1.31 ([#3417]) ### Fixed - Fix "name / parent" variant of `event!` ([#2983]) - Remove 'r#' prefix from raw identifiers in field names ([#3130]) - Fix perf regression when `release_max_level_*` not set ([#3373]) - Use imported instead of fully qualified path ([#3374]) - Make `valueset` macro sanitary ([#3382]) ### Documented - **core**: Add missing `dyn` keyword in `Visit` documentation code sample ([#3387]) [#2983]: https://github.com/tokio-rs/tracing/pull/#2983 [#3130]: https://github.com/tokio-rs/tracing/pull/#3130 [#3158]: https://github.com/tokio-rs/tracing/pull/#3158 [#3227]: https://github.com/tokio-rs/tracing/pull/#3227 [#3373]: https://github.com/tokio-rs/tracing/pull/#3373 [#3374]: https://github.com/tokio-rs/tracing/pull/#3374 [#3382]: https://github.com/tokio-rs/tracing/pull/#3382 [#3387]: https://github.com/tokio-rs/tracing/pull/#3387 [#3398]: https://github.com/tokio-rs/tracing/pull/#3398 [#3414]: https://github.com/tokio-rs/tracing/pull/#3414 [#3417]: https://github.com/tokio-rs/tracing/pull/#3417 [`Span::record_all`]: https://docs.rs/tracing/0.1.41/tracing/struct.Span.html#method.record_all
hds
added a commit
that referenced
this pull request
Nov 26, 2025
# 0.1.42 (November 26, 2025) ### Important The [`Span::record_all`] method has been removed from the documented API. It was always unsuable via the documented API as it requried a `ValueSet` which has no publically documented constructors. The method remains, but should not be used outside of `tracing` macros. ### Added - **attributes**: Support constant expressions as instrument field names ([#3158]) - Add `record_all!` macro for recording multiple values in one call ([#3227]) - **core**: Improve code generation at trace points significantly ([#3398]) ### Changed - `tracing-core`: updated to 0.1.35 ([#3414]) - `tracing-attributes`: updated to 0.1.31 ([#3417]) ### Fixed - Fix "name / parent" variant of `event!` ([#2983]) - Remove 'r#' prefix from raw identifiers in field names ([#3130]) - Fix perf regression when `release_max_level_*` not set ([#3373]) - Use imported instead of fully qualified path ([#3374]) - Make `valueset` macro sanitary ([#3382]) ### Documented - **core**: Add missing `dyn` keyword in `Visit` documentation code sample ([#3387]) [#2983]: https://github.com/tokio-rs/tracing/pull/#2983 [#3130]: https://github.com/tokio-rs/tracing/pull/#3130 [#3158]: https://github.com/tokio-rs/tracing/pull/#3158 [#3227]: https://github.com/tokio-rs/tracing/pull/#3227 [#3373]: https://github.com/tokio-rs/tracing/pull/#3373 [#3374]: https://github.com/tokio-rs/tracing/pull/#3374 [#3382]: https://github.com/tokio-rs/tracing/pull/#3382 [#3387]: https://github.com/tokio-rs/tracing/pull/#3387 [#3398]: https://github.com/tokio-rs/tracing/pull/#3398 [#3414]: https://github.com/tokio-rs/tracing/pull/#3414 [#3417]: https://github.com/tokio-rs/tracing/pull/#3417 [`Span::record_all`]: https://docs.rs/tracing/0.1.41/tracing/struct.Span.html#method.record_all
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!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
I'm on tracing v0.1.40 and cannot use macro
and its variants (
debug!(), etc) due to errorLooks like it was just missed out by accident