Skip to content

Add #[track_caller] to with_gil. #5109

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

Merged
merged 2 commits into from
May 4, 2025
Merged

Add #[track_caller] to with_gil. #5109

merged 2 commits into from
May 4, 2025

Conversation

m-ou-se
Copy link
Contributor

@m-ou-se m-ou-se commented May 4, 2025

No description provided.

@alex
Copy link
Contributor

alex commented May 4, 2025

My (clearly limited) understanding was that track_caller caused panics arising in the function to be attributed to the caller. But in this case neither of these functions can directly panic (though functions they call, recursively, can, I think?). What's the expected behavior here?

@m-ou-se
Copy link
Contributor Author

m-ou-se commented May 4, 2025

f can be #[track_caller] and panic. If with_gil is not #[track_caller], then with_gil(f) will report a panic location inside of with_gil.

@alex
Copy link
Contributor

alex commented May 4, 2025

To make sure I have this, the only case this changes behavior is if f is also #[track_caller].

For f which is not #[track_caller] this is the same before/after -- the panic is attributed to f.

For f which is #[track_caller], without this PR if f panics then the panic is attributed to with_gil. With this PR, the panic is properly attributed to with_gil's caller?

@m-ou-se
Copy link
Contributor Author

m-ou-se commented May 4, 2025

Correct!

@alex
Copy link
Contributor

alex commented May 4, 2025

This makes sense to me as an improvement.

Does this imply that basically any function which accepts an impl Fn should be #[track_caller] for the same reason?

@m-ou-se
Copy link
Contributor Author

m-ou-se commented May 4, 2025

Maybe. Probably. Applying #[track_caller] to a closure is currently an unstable Rust feature, so it's somewhat unlikely people will run into this, unless they're using nightly features or if they're passing a function name rather than a closure.

@alex
Copy link
Contributor

alex commented May 4, 2025

Ah, so this is 99% preventative. (I mean, you can just pass a regular fn, but I suspect very few people do.)

Thanks for the comprehensive answers.

@alex alex enabled auto-merge May 4, 2025 13:18
@alex alex added this pull request to the merge queue May 4, 2025
Merged via the queue into PyO3:main with commit 5a3de05 May 4, 2025
43 of 44 checks passed
@m-ou-se m-ou-se deleted the track-caller branch May 4, 2025 15:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants