stabilize format args capture

[joshtriplett]

Works as expected, and there are widespread reports of success with it, as well as interest in it.

RFC: rust-lang/rfcs#2795
Tracking issue: #67984

Addressing items from the tracking issue:

• We don't support capturing arguments from a non-literal format string like format_args!(concat!(...)). We could add that in a future enhancement, or we can decide that it isn't supported (as suggested in Tracking issue for format_args_capture #67984 (comment) ).
• I've updated the documentation.
• panic! now supports capture as well.
• There are potentially opportunities to further improve diagnostics for invalid usage, such as if it looks like the user tried to use an expression rather than a variable. However, such cases are all already caught and provide reasonable syntax errors now, and we can always provided even friendlier diagnostics in the future.

[rust-highfive]

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

[joshtriplett]

@rust-lang/lang, shall we stabilize println!("{local_variable}") and family, now that we've shipped Rust 2021 with working panic!("{local_variable}") support?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[m-ou-se]

panic! now supports capture as well.

Note that many macros in the ecosytem do not support this right now. E.g. anyhow!("{x}") will just produce an error with the message "{x}".

[joshtriplett]

@m-ou-se True, but I don't think that should be a blocker to stabilization. I do think that the release notes for the release stabilizing this should encourage propagating this behavior, though.

[m-ou-se]

It might be a good idea to inform the maintainers of popular crates with such a macro now. Once this stabilizes their users will probably expect it to work with their macros too.

cc @dtolnay for anyhow.
cc @yaahc for eyre.

If I find the time for it, I'll try to hack together some regex to find other crates with a similar macro.

[joshtriplett]

cc @hawkw for tracing.

[nikomatsakis]

Is there a PR adding this to the reference?

[hawkw]

cc @hawkw for tracing.

I think this ought to work fine with tracing out of the box without any work on our end — when a user adds a format_args! message to a tracing macro, we just capture all the tokens as a repeated set of token trees, and pass them directly to a format_args! invocation. So, as far as I know, any format args accepted by format_args! should be accepted by tracing as well without any changes on our part!

[nikomatsakis]

@rfcbot reviewed

Josh pointed out in the lang team meeting that this doesn't need to appear in the rust-lang reference, as it's (conceptually, at least) a library feature, and those docs are updated. Huzzah!

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

I was going to be scared if this affected tokenization, but because it doesn't take general expressions, 👍

[m-ou-se]

I think this ought to work fine with tracing out of the box without any work on our end

Yup, log and tracing and many others always use format_args, so don't require any changes:

error: there is no argument named `x`
 --> src/main.rs:2:21
  |
2 |     tracing::info!("{x}");
  |                     ^^^
  |
  = help: if you intended to capture `x` from the surrounding scope, add `#![feature(format_args_capture)]` to the crate attributes

The only problem is macros that special-case the single argument case to skip format_args!(). E.g. Rust 2015/2018's panic!("{x}") and Anyhow's anyhow!("{x}") (etc.) (dtolnay/anyhow#55).

[bors]

☔ The latest upstream changes (presumably #90516) made this pull request unmergeable. Please resolve the merge conflicts.

[rust-timer]

Finished benchmarking commit (c26746a): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression