Use std::panic::Location for file & line information

[pwoolcoc]

this commit adds a feature, track_caller, that allows the user to opt-in to using location information from std::panic::Location instead of the built-in file! and line! macros. This will allow log record location information to be manipulated in the same way that #[track_caller] allows panic location information to be manipulated

[Thomasdezeeuw]

Is there a benefit to doing this?

[Thomasdezeeuw]

Ah, sorry didn't see the second part of your comment, ignore my previous comment.

[pwoolcoc]

It allows you to manipulate location information for log messages in the same way that you can for panic! messages. For example, one of my applications has a generic "retry-er" that takes a closure and a retry policy, and will run the closure until it gets a successful return value from the closure or until it hits it's max retries. Currently, any logging we do from the retryer (like "got error Foo, retry 1/10") will include location information from inside the retryer, but no identifying information about exactly which closure generated the error. Of course, we could simply pass more information to the retryer to help us identify the piece of code that is erroring out, but I thought it would be possible to use #[track_caller] for this instead, to keep the API cleaner. Turns out I couldn't use log::error!, log::warn!, etc, because those macros use file!() and line!(). I can do it if I write my own log::Record-generating code, but I thought having this functionality built-in to log might be useful for others.

[jdm]

This will break compilation of log with rustc < 1.46, even without the track_caller feature enabled. The following will allow compilation to succeed without that feature enabled:

        #[cfg(feature = "track_caller")]
        {
            ::std::panic::Location::caller().file()
        }
        #[cfg(not(feature = "track_caller"))]
        {
            file!()
        }

[sfackler]

This cfg is evaluated in the context of the crate that invokes a log macro, not the context of the log crate so this won't work.

[pwoolcoc]

thanks @sfackler, I pushed an update so they're evaluated in the correct context

[pwoolcoc]

r? @sfackler @jdm

[jdm]

My earlier concern has been addressed, but otherwise I'm just a bystander :)

[pwoolcoc]

no problem, thanks!

[pwoolcoc]

bump, can someone take a look at this?

[KodrAus]

Thanks @pwoolcoc! If MSRVs weren't a concern this is probably something we'd want unconditionally, wouldn't we? If that's the case I think we could use our build.rs to detect 1.46.0 support and just enable it quietly instead of using an explicit feature.

[KodrAus]

I think we could detect 1.46.0 in our build.rs and quietly enable this.

[KodrAus]

Just coming in through some triage. I think the only outstanding thing here was using our build script to automatically use track_caller if we're on at least 1.46.0.

[jrose-signal]

Since this PR was left off, the MSRV has been bumped to 1.60. I think that means this can/should be turned on unconditionally!

[Thomasdezeeuw]

@pwoolcoc is this something you're still interested in? We've updated our MSRV to 1.60 so this can be done now.

[pwoolcoc]

@Thomasdezeeuw yes, but as I deleted my original fork, I can't seem to update this PR, so I'll have to open a new PR.

[pwoolcoc]

Closing in favor of #599