Fix format_args capture for macro expanded format strings#102519
Fix format_args capture for macro expanded format strings#102519bors merged 1 commit intorust-lang:masterfrom
format_args capture for macro expanded format strings#102519Conversation
912aa69 to
41b8f7e
Compare
41b8f7e to
71db0dd
Compare
|
Thanks! @bors r+ |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (edadc7c): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
|
Hm, this slowed down rustc compiler bootstrap by almost a minute (8%) ?? on perf.rlo |
|
Seems pretty unlikely as this just changes a snippet span back to what it was a few days ago |
…-ou-se Fix `format_args` capture for macro expanded format strings Since rust-lang#100996 `format_args` capture for macro expanded strings aren't prevented when the span of the expansion points to a string literal, e.g. ```rust // not a terribly realistic example, but also happens for proc_macros that set // the span of the output to an input str literal, such as indoc macro_rules! x { ($e:expr) => { $e } } fn main() { let a = 1; println!(x!("{a}")); } ``` The tests didn't catch it as the span of `concat!()` points to the macro invocation r? `@m-ou-se`
Since #100996
format_argscapture for macro expanded strings aren't prevented when the span of the expansion points to a string literal, e.g.The tests didn't catch it as the span of
concat!()points to the macro invocationr? @m-ou-se