-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#[track_caller] on closures? #74042
Comments
cc @eddyb I cant' recall right now whether this restriction is a requirement of the implementation we chose or whether we just left it as-designed in the RFC. Can you? |
If there is no technical reason not to support it, I would think we should. I imagine one challenge is that calls to closures are being dispatched through the |
I would expect this to "just work", if the attribute syntax parses. |
Although... the example is a bit suspect, it doesn't specify what the expected behavior is, but the call of the closure in the If you want to propagate all the way to We could also try to make a way to override the "caller location" of a call (and pass in an outer one), but the ergonomics of that are worse for this example (where |
Ha! That's interesting, I didn't think about the fact that I'm not actually the one calling the closure, so my |
I had assumed that, in the example, the |
I've opened #74492 with a bare minimum change and test included. It's currently failing because MIR argument counts aren't happy. I'll dig in at some point soon, if anyone has suggestions I'm all ears. |
Is there some way of doing that? I'm trying to do something in the same vein as the original post, but using A made-up example: use core::panic::Location;
#[track_caller]
fn demo(r: Result<u8, String>) -> Result<u8, String> {
let location = Location::caller();
r.map_err(|e| {
Location::pretend_we_are_at(location);
another_function();
e
})
}
#[track_caller]
fn another_location() {} Another route would be if I could get access to the inner implementation of r.map_err(|e| {
#[delegate_caller_location(location)]
another_function();
e
}) |
track_caller is unstable and seems to now be guarded behind a feature flag: rust-lang/rust#74042 We also have one test for large objects that is very slow under ASan.
track_caller is unstable and seems to now be guarded behind a feature flag: rust-lang/rust#74042 We also have one test for large objects that is very slow under ASan.
One problem I have is that it's not possible to put
#[track_caller]
on closures, this is really useful whenthread_local
is involved because then there's a lot of logic in closures that you might want to propagateie
Originally posted by @elichai in #47809 (comment)
The text was updated successfully, but these errors were encountered: