`try_trait_v2` changed the location of the `From::from` caller so the stack trace is different.

[artemii235]

Initial report #84277 (comment)

We have a problem in our project related to the new question mark desugaring. We use the track_caller feature in From::from implementation of the error types to collect stack traces with generics and auto and negative impl traits magic implemented by @sergeyboyko0791 (https://github.com/KomodoPlatform/atomicDEX-API/blob/mm2.1/mm2src/common/mm_error/mm_error.rs).

After updating to the latest nightly toolchain this stack trace collection started to work differently. I've created a small project for the demo: https://github.com/artemii235/questionmark_track_caller_try_trait_v2

cargo +nightly-2021-05-17 run outputs Location { file: "src/main.rs", line: 18, col: 23 } as we expect.

cargo +nightly-2021-07-18 run outputs Location { file: "/rustc/c7331d65bdbab1187f5a9b8f5b918248678ebdb9/library/core/src/result.rs", line: 1897, col: 27 } - the from_residual implementation that is now used for ? desugaring.

Is there a way to make the track caller work the same way as it was before? Maybe we can use some workaround in our code?

Thanks in advance for any help!

[artemii235]

As per #84277 (comment), applying #[track_caller] to Result::from_residual will bloat a lot of callers. Can this be applied conditionally? If From::from has #[track_caller] then Result::from_residual will have it too, otherwise not.

[thomaseizinger]

So, if I understand you correctly, then what your code is trying to achieve is to create a stacktrace of all invocations of ?.

To my knowledge, this is tracked as "error return traces" here: rust-lang/project-error-handling#9

[nicholastmosher]

I am seeing this same problem using the Location feature from eyre/color-eyre, which appeared after updating to 1.54

[artemii235]

So, if I understand you correctly, then what your code is trying to achieve is to create a stacktrace of all invocations of ?.

Yes, and we actually achieved it in a different way. As I can see the RFC mentioned in rust-lang/project-error-handling#9 is not merged so it has no guarantee to be implemented.

I think this issue can be considered as broken backward compatibility because our use case worked fine before the try_trait_v2 implementation. Hopefully, there is a workaround that won't take too much effort.

[BGR360]

@artemii235 I want to do a very similar thing to your MmError, but directly leveraging the try_trait_v2. For your reference, the workaround that I am experimenting with at my work is to simply write a new Result<T, E> type that wraps std::result::Result<T, E> and implement the FromResidual myself with #[track_caller].

We considered if we could do it by just patching the std library to add #[track_caller] to from_residual, but we want to capture invocations of ? even when the residual is the same type as the output. So we sort of have to do the chaining inside of from_residual rather than inside some impl From.

In your case, it looks like MmError punts on being able to detect ? events when the error type doesn't change, so if your suggestion is accepted, sounds like that will help you.

[nikomatsakis]

Can somebody describe to me what the original code was trying to do? Was it to dynamically reconstruct a stack trace around the ? operator?

[BGR360]

That is correct, to the best of my knowledge.

[sergeyboyko0791]

@nikomatsakis exactly. The main goal is to track sequentially the places where one error E1 converts to another E2.
The location is tracked every time the ? operator calls the from function tagged as track_location:

https://github.com/KomodoPlatform/atomicDEX-API/blob/mm2.1/mm2src/common/mm_error/mm_error.rs#L131

[yaahc]

@artemii235 I want to do a very similar thing to your MmError, but directly leveraging the try_trait_v2. For your reference, the workaround that I am experimenting with at my work is to simply write a new Result<T, E> type that wraps std::result::Result<T, E> and implement the FromResidual myself with #[track_caller].

We considered if we could do it by just patching the std library to add #[track_caller] to from_residual, but we want to capture invocations of ? even when the residual is the same type as the output. So we sort of have to do the chaining inside of from_residual rather than inside some impl From.

In your case, it looks like MmError punts on being able to detect ? events when the error type doesn't change, so if your suggestion is accepted, sounds like that will help you.

I think this is the correct solution going forward that people should reach for when implementing error types that utilize track caller. As Mara mentioned in #88302 (comment) we don't consider track_caller results to be part of our stable API surface, similar to Debug output. That plus @dtolnay indicated that the old track caller support on Result caused significant performance loss in serde compared to manual matches means we likely won't add #[track_caller] back to the new try trait impls for Result and will instead rely on users to implement custom try types when needed as described by @BGR360.

@BGR360 if you plan on publishing a crate for this lmk, otherwise I'll add this to the todo list for the error handling project group.

[BGR360]

@yaahc I'm still pretty new to Rust so I don't really feel qualified to author a general purpose crate for this, nor do I really trust myself to maintain it for the community 😁 . I would be happy to help contribute to the development of a crate, though, and/or to participate in discussion around this topic.

What work would you be adding to the project-error-handling todo list for this? The creation of a new crate? Or some sort of new std library feature?