- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
          Fix format_args capture for macro expanded format strings
          #102519
        
          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
Conversation
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