Remove sys::begin_unwind_?

[catamorphism]

I presume what was intended here is to merge it into begin_unwind; comment says "temporary until rt_fail_ goes away". However, rt_fail_ hasn't gone away yet.

[catamorphism]

So, rt_fail_ appears to have gone away, but I can't figure out what was intended by the original fixme. begin_unwind_ is still used and takes a string, filename, and line number, whereas the begin_unwind method on Unwinder doesn't. @graydon ?

[pnkfelix]

@catamorphism From reading commit 3fcdb7d where the original FIXME was injected and which introduced begin_unwind_, it looks like begin_unwind_ was originally called from only two places: rt_fail_ and begin_unwind.

So I suspect the intention of the FIXME was to say "once we get rid of rt_fail_, we should manually inline the body of begin_unwind_ into begin_unwind and then get rid of begin_unwind_ itself.

I'll try to do that now.

[pnkfelix]

Of course, commit 3fcdb7d also ensured that its begin_unwind and begin_unwind_, which both lived in sys.rs, had the same signature. I poked around a little, it looks to me like @catamorphism was talking about a different begin_unwind method of the Unwinder struct (currently in std::rt::task though at the time of @catamorphism's comment it was in core::rt::local_services).

Anyway, at this point, there are now six callers of begin_unwind_; two of them live in sys.rs right next to begin_unwind_ (those probably replaced the earlier begin_unwind from commit 3fcdb7d), a third is fail_ from libstd/unstable/lang.rs, and the remaining three are in std::rt::borrowck (my reaction to that last one: "reallly? weird.")

[pnkfelix]

In case it is not clear, I was visiting this bug for triage last week, for 2013-07-15. I had thought it would be easy to fix this based on my analysis from my earlier comment. But further investigation revealed that new external callers of begin_unwind_ have been introduced. I spent some time trying to at least change the interface used by the external callers to not use unsafe code (e.g. not use native pointers to null terminated strings) but that did not appear to be an easy local transformation in the majority of the cases.

[brson]

This was never nominated and isn't really a backwards compatibility issue as long is this is an unstable API. Removing milestone.