Closed
Description
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.