Change Location<'_> lifetime to 'static in Panic[Hook]Info

[ijchen]

I'm writing a library that would benefit from being able to store a &'static str instead of a String for the file location of a panic. Currently, the API of std::panic::PanicHookInfo::location and core::panic::PanicInfo::location return a Location<'_> (and by extension, a file name &str) whose lifetime is tied to the borrow of the Panic[Hook]Info.

It is my understanding that the Location/&str will always be Location<'static>/&'static str, since the file name is embedded directly into the compiled binary (and I don't see a likely reason/way for that to ever change in the future). Since it seems unlikely to ever need to change, and since making the guarantee that the returned lifetime is 'static has a real benefit (allows users to avoid unnecessary allocations), I think changing to the returned Location<'_>'s lifetime to 'static would be a worthwhile change.

see also the recent #1320870, which made a similar change to std::panic::Location

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Amanieu]

Considering that the only way to construct a location is Location::caller which returns a &'static Location<'static> (this is used internally by the panic macros and compiler-generated panics), we could make these methods return a &'static Location<'static> as well. I don't see any value in a non-'static version of this unless we plan to allow constructing custom locations (which seems unlikely).

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ijchen]

That's a great idea! I've updated accordingly.

[Amanieu]

@rfcbot merge

[rust-rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @the8472

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.