Support #[track_caller] on closures.

[anp]

Closes #74042.

[rust-highfive]

r? @lcnr

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

[anp]

Fails locally with:

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `2`,
 right: `3`: #[track_caller] fn's must have 1 more argument in their ABI than in their MIR'

[lcnr]

afaik closures use FnOnce::call_once, which has the "rust-call" calling convention.

This calling convention takes the argument list and wraps them in a tuple to support generics.
Not sure what has to be done about that here though 🤔

[anp]

Thanks! That jogged my memory for the portion of codegen to look at. Since the assertion is there to prevent miscompilation I tried commenting it out and the argument passing appeared to "just work". Will still need to figure out the right number to assert on in the presence of untupled args but that can be done later.

The next issue is that the "definition span" we get for a closure-as-fn-ptr appears to be in libcore:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"/home/adam/rust/src/libcore/ops/function.rs"`,
 right: `"/home/adam/rust/src/test/ui/rfc-2091-track-caller/track-caller-closure.rs"`', /home/adam/rust/src/test/ui/rfc-2091-track-caller/track-caller-closure.rs:52:5

I think this will need to be modified in

rust/src/librustc_mir/interpret/intrinsics/caller_location.rs

Line 17 in 2210abe

crate fn find_closest_untracked_caller_location(&self) -> Span {

but I might be wrong and it might also require special closure logic when resolving fn ptrs in

rust/src/librustc_middle/ty/instance.rs

Line 375 in 2666aed

pub fn resolve_for_fn_ptr(

.

cc @eddyb btw

[eddyb]

Sounds like you need to make some of the Fn-trait-related shims pretend to have #[track_caller] depending on whether the underlying function/closure does. I didn't think about that when I suggested closures "should just work" but:

You might be able to get away with testing a case where a closure doesn't implement more than FnOnce (e.g. capture something like a String that is entirely consumed by the closure body), because that shouldn't get any shims.

Then again, you mention coercing to a fn pointer being the only case that doesn't work, I'm not sure what the best solution for that is, maybe checking that we're in a reify shim and doing Instance::resolve on the DefId/Substs pair of the reify shim? That way, we may get back an InstanceDef::Item referring to the closure, or a shim that makes it clear what the closure DefId is?

[bjorn3]

If the abi is "Rust-call" then the argument count is 1 (for the self argument) + the amount of elements in the type of the second argument (the operands bundle, which is a tuple).

[Dylan-DPC-zz]

@anp any updates?

[bors]

☔ The latest upstream changes (presumably #74932) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC-zz]

@anp thanks for taking the time to contribute. Sadly this PR is inactive so I'm going to close it. If you wish and you have the time to complete this, you can open a new pull request and we'll take it from there.