Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

info!/error!/warn! macros don't accept constants for first field name #2837

Closed
tim3z opened this issue Dec 21, 2023 · 2 comments
Closed

info!/error!/warn! macros don't accept constants for first field name #2837

tim3z opened this issue Dec 21, 2023 · 2 comments

Comments

@tim3z
Copy link

tim3z commented Dec 21, 2023

Version

tracing v0.1.40
    ├── tracing-attributes v0.1.27 (proc-macro)
    └── tracing-core v0.1.32

Platform

macOS 13.6
Darwin HAMACL00492 22.6.0 Darwin Kernel Version 22.6.0: Tue Nov 7 21:40:08 PST 2023; root:xnu-8796.141.3.702.9~2/RELEASE_ARM64_T6000 arm64

stable-aarch64-apple-darwin (default)
rustc 1.74.1 (a28077b28 2023-12-04)

Description

I expected the following sample to compile. The problem is the same on all the different log levels (I tried only info, warn and error)

const FOO: &str = "foo";
fn main() {
    tracing::info!(bar = 42, { FOO } = 23, "tada"); // works
    tracing::event!(tracing::Level::INFO, { FOO } = 23, bar = 42, "tada"); // works, too
    tracing::info!({ FOO } = 23, bar = 42, "tada"); // doesn't compile
}
@ItsEthra
Copy link

I don't think they should compile. The same behavior is present in println, format, etc. Because those macros accept a string literal. Also I believe info, warn, error, etc all use format_args internally which also requires a string literal so it just wouldn't be possible.

@mladedav
Copy link
Contributor

mladedav commented Feb 17, 2024

This should compile, the docs say that you can use constant expressions as names. There just seems to be an issue with it being the first field because { ... } is already handled specially.

There's a test for this, it just doens't use the constant in the first position so this should probably be expanded and then fixed.

In the meantime, you can put the fields in another set of curly braces which should work as expected:

tracing::info!({{ FOO } = 23, bar = 42}, "tada");

@hawkw hawkw closed this as completed in 908cc43 Mar 1, 2024
dpc pushed a commit to dpc/tracing that referenced this issue 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)+ })
    );
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants