Add #[track_caller] to the "From implies Into" impl

[Emilgardis]

This pr implements what was mentioned in #77474 (comment)

This follows from my URLO https://users.rust-lang.org/t/104497

#![allow(warnings)]
fn main() {
    // Gives a good location
    let _: Result<(), Loc> = dbg!(Err::<(), _>(()).map_err(|e| e.into()));

    // still doesn't work, gives location of `FnOnce::call_once()`
    let _: Result<(), Loc> = dbg!(Err::<(), _>(()).map_err(Into::into));
}

#[derive(Debug)]
pub struct Loc {
    pub l: &'static std::panic::Location<'static>,
}

impl From<()> for Loc {
    #[track_caller]
    fn from(_: ()) -> Self {
        Loc {
            l: std::panic::Location::caller(),
        }
    }
}

[rustbot]

r? @joshtriplett

(rustbot has picked a reviewer for you, use r? to override)

[Emilgardis]

This is a tiny but huge change, so probably needs a perf run if this ever is accepted, as mentioned earlier.

[fmease]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 075f2e0 with merge 902a98b...

[bors]

☀️ Try build successful - checks-actions
Build commit: 902a98b (902a98b337af1a2df4a8520fa7ca0eb92a5513de)

[rust-timer]

Finished benchmarking commit (902a98b): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.4%	[-1.4%, -1.4%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.5%, 1.0%]	3
Regressions ❌ (secondary)	1.2%	[1.2%, 1.2%]	2
Improvements ✅ (primary)	-1.0%	[-1.0%, -1.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-1.0%, 1.0%]	4

Cycles

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-0.6%, -0.6%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 666.26s -> 665.429s (-0.12%)
Artifact size: 308.39 MiB -> 308.40 MiB (0.00%)

[Emilgardis]

Is that enough to validate this atleast? Don't know how many calls that are affected are hit in the runs, would it maybe be possible/needed to crater + perf instruction count?

[Noratrieb]

We will almost certainly get inlining here in one direction, either inlining from into into or if that doesn't happen, inlining into into the caller (or probably in many cases, both). Due to this, I don't expect this to have a large a overhead, track_caller is just a single pointer argument after all, which will be a lot smaller compared to the from impl (and if the from impl is small, then everything will be inlined and there won't be any overhead from track_caller).
rustc-perf agrees with this assessment, so I'm going to approve this. If anyone finds this to be a performance problem (which seems unlikely to me), we can always revert it.
@bors r+ rollup=never

[bors]

📌 Commit 075f2e0 has been approved by Nilstrieb

It is now in the queue for this repository.

[bors]

⌛ Testing commit 075f2e0 with merge d9d89fd...

[bors]

☀️ Test successful - checks-actions
Approved by: Nilstrieb
Pushing d9d89fd to master...

[rust-timer]

Finished benchmarking commit (d9d89fd): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.4%	[0.4%, 0.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-2.6%	[-3.8%, -1.4%]	2
All ❌✅ (primary)	-2.8%	[-2.8%, -2.8%]	1

Cycles

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 663.269s -> 662.236s (-0.16%)
Artifact size: 308.35 MiB -> 308.38 MiB (0.01%)

[tiberiusferreira]

Hey, I just got bitten by the:

// still doesn't work, gives location of FnOnce::call_once()
let _: Result<(), Loc> = dbg!(Err::<(), _>(()).map_err(Into::into));

Is there a tracking issue for this?

[Emilgardis]

Is there a tracking issue for this?

I don't believe there is.
Edit::
Possibly #105942