Inline core::panic::Location methods

[overdrivenpotato]

This avoids the overhead of a function call when used.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @kennytm

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

[the8472]

For caller this was tried previously and had to be reverted, see #95735

[overdrivenpotato]

@the8472 Isn't that a bug in bjorn3/rustc_codegen_cranelift rather than a responsibility of libcore? Perhaps that is a symptom of a bigger issue in that project, regarding inlined #[track_caller] functions.

[the8472]

I'm just pointing out the issue, I'm no cranelift expert. But cranelift is an official, although experimental, compiler backend so libcore has to work with it too.

[bjorn3]

Perhaps that is a symptom of a bigger issue in that project, regarding inlined #[track_caller] functions.

Looks like the implementation of #[track_caller] in cg_llvm changed since I implemented it in cg_clif. I will try to apply the changes to cg_clif and report back.

[bjorn3]

That was indeed the issue. Pushed rust-lang/rustc_codegen_cranelift@f3fc94f with a fix. Adding #[inline] to Location::caller() is fine with me.

[bjorn3]

By the way feel free to ping me about anything regarding the cranelift backend.

[overdrivenpotato]

Great, thanks for clarifying @bjorn3. Do you have the ability to merge this PR?

[bjorn3]

Technically I can approve it. However I don't feel qualified to review non-compiler changes.

[the8472]

The rationale from the previously approved PR should still apply. It's not an API change. And @bjorn3 fixed the reason for the revert. So this should be fine.

Disabling rollup since the queue is almost empty and this changes a few more methods to inline, compared to the previous PR.

@bors r+ rollup=never

[bors]

📌 Commit 92a5841 has been approved by the8472

[bors]

⌛ Testing commit 92a5841 with merge 579d268...

[bors]

☀️ Test successful - checks-actions
Approved by: the8472
Pushing 579d268 to master...

[rust-timer]

Finished benchmarking commit (579d268): comparison url.

Summary:

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 😿 relevant regressions found

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	0	11	0	0	0
mean2	N/A	0.5%	N/A	N/A	N/A
max	N/A	0.8%	N/A	N/A	N/A

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

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[overdrivenpotato]

The inlining here only changes function calls to register loads, so this seems spurious. https://godbolt.org/z/41YhbWfEr

@rustbot label: +perf-regression-triaged