Allow setting breakpoint when Err() is constructed in debug builds

[jrmuizel]

This would be really helpful for tracking down the source of errors. It seems the simplest way to allow this would be to emit a no-inline function that's used for setting a particular enum variant.

[est31]

The failure crate has a backtrace option. Alternatively, you can shadow the try! macro in your project.

[jrmuizel]

Neither of those work universally though. I'm looking for a solution that works across crates not under my control.

[jrmuizel]

The Err variant has a lang item associated with it. It should be possible to introduce the function call during HIR to THIR translation. I'm not sure if lang item data gets kept after the translation to THIR so I don't know if it's possible to do later.

[CinchBlue]

FYI this popped up in StackOverflow bountied questions list for rust near the top:

How to break on Err creation

From my assessment, it seems like this is still not possible on 1.63.0? Or is this wrong?

[abhi-k9]

This needs to be a thing. Tracking where Err originated from in a deep call-stack is tough, and time-consuming at minimum.

[jrmuizel]

I implemented this here: https://github.com/jrmuizel/rust/tree/break-on-err-construction. One thing I ran into is that Err can be constructed a lot in the normal running of a program: e.g. https://doc.rust-lang.org/std/sync/atomic/struct.AtomicI64.html#method.compare_exchange

My changes give a unique code location for each Err construction so it's possible to disable the uninteresting breakpoints but depending on the program that can be a lot for work.

It might be more practical to use with RR where you can just run in reverse.