Rename begin_unwind lang item and core function

[brson]

The unwind code has had a long and storied life. Currently there are two naming conventions in use: fail and begin_unwind, the code for which is divided between core::failure and rustrt::unwind.

In the rustrt case, the naming is accurate because the runtime provides unwinding, but core, which contains two functions named begin_unwind, one of which is a lang item, provides no particular failure semantics, and ultimately the language definition will allow for different implementations of failure.

The four 'core' failure functions are:

// Compiler-emitted failure
#[lang="fail_"]
fn fail_(expr_file_line: &(&'static str, &'static str, uint)) -> !;

// Compiler-emitted index oob failure
#[lang="fail_bounds_check"]
fn fail_bounds_check(file_line: &(&'static str, uint),
                     index: uint, len: uint) -> !;

// Library-emitted `fail!` calls inside the std facade
pub fn begin_unwind(fmt: &fmt::Arguments, file_line: &(&'static str, uint)) -> !;

// The declaration of the lang item that actually implements failure.
// All failure goes through this method which must be provided downsteam,
// and is implemented in the 'std' crate.
extern {
    #[lang = "begin_unwind"]
    fn begin_unwind(fmt: &fmt::Arguments, file: &'static str, line: uint) -> !;
}

The begin_unwind lang item and the function core::failure::begin_unwind should be renamed to be implementation-agnostic. Perhaps fail_fmt and fail_impl.

[alexcrichton]

While we're renaming, we could rename fail_ to fail as well now that it's not a keyword.

I'd also vote for fail_fmt

[brson]

I can mentor.

[brson]

A patch implementing this will conflict with #16100 until it lands.

[metalogical]

I'm interested in taking a look at this (first time touching the codebase). I've spent a little time trying to understand how the begin_unwind lang item is used internally, but I'm a little confused by the difference between the begin_unwind and rust_begin_unwind identifiers in librustc/middle/lang_items.rs and weak_lang_items.rs, as well as the variants defined in librustrt/unwind.rs

[brson]

@namanbharadwaj 'weak lang items' are lang items that the compiler may emit calls to, even if the required code has not yet been defined in any upstream crates. In the case of begin_unwind it also allows library code to call into a runtime function that doesn't yet exist. This is specifically to allow code in crate core to initiate stack unwinding (which is defined in rustrt).

The way it does this is by relying on the linker to make the lang item's symbol available during the final application link step. What this means in practice is that calls to the begin_unwind extern declared in core end up as calls to the begin_unwind definition in rustrt. Because these lang items have unmangled symbols, their definitions are prefixed rust_ so they don't clash with other symbols.

Hope that helps.

[metalogical]

That helps a lot, thanks! I've made a bunch of changes to rename the lang item, but I've just realized that I'm going to run into bootstrapping issues, as the snapshot will be looking for the begin_unwind lang item and does not know about any fail_fmt lang item.

Seems like we will need some intermediate versions that know about both begin_unwind and fail_fmt, but I'm not precisely sure how that will work.