Better backtrace cleaning on panic

[Yamakaky]

Followup of #38165.

The current behaviour is to maintain a blacklist of frames to remove from the backtrace. This poses problems in portability and accuracy. For example, the bottom of the backtrace is not cleaned when the panic is in a test or an other thread.

I propose that just before calling the user main/test/closure, the calling code would capture a backtrace. Then, on panic, the frames present is the backtrace pre and post panic would be removed. That way, no need to have a big whitelist. Some small post-processing may be needed to remove some additional frames.

A few questions:

• Is __rust_maybe_catch_panic used on all the platforms? If so, it could be used as a basis for this technique, since it's used for tests, the main thread and the secondary threads.

[Yamakaky]

r? @alexcrichton

[alexcrichton]

I don't think we should too aggressively try to clean backtraces because we run the risk of hiding actually useful information.

I'd be against capturing a backtrace at the beginning of tests/main/etc as that's somewhat surprising and we should otherwise be able to infer the bottom of the stack. I'd be fine just adding more heuristics.

[Yamakaky]

What do you mean by surprising?

[alexcrichton]

It's a pretty weighty piece of code to unconditionally run, it's also quite slow. We should avoid running it by default.

[Yamakaky]

Not wrong

[petrochenkov]

@Yamakaky
I thought you were going to detect main and friends by their symbol names, not by literally producing a backtrace.

[Yamakaky]

No, that's what I meant.