Implement fail as a macro/library function

[brson]

It will not be difficult to eliminate fail from the language, but there are some considerations: a) it has to work with or without an argument (we could just have two); b) in the future it will probably need to accept any sendable type argument, not just a string; c) it has to report the correct location of the error.

[nikomatsakis]

(c) seems to argue for a macro. The macro could also address (a) without requiring two distinct forms. (b) seems easy enough to solve using generic types.

[catamorphism]

I opened an issue - #2245 - for the #file and #line macros that we need for this.

[kud1ing]

#2245 is implemented now

[eholk]

I thought another key feature of fail was that typestate knew it never returned and could stop checking after branches that fail. Can we do that with a macro?

[brson]

eholk: we also have the '!' return type that gives us the same information, so we can presumably declare in intrinsic that returns !

[eholk]

Oh right, I forgot about that.

[bblum]

With this issue, do we intend to tear out the unwinding bits in the runtime, too? Or just have it call into task::fail which calls rustrt::rust_task_fail?

[elliottslaughter]

This has been (partially) implemented in de82a9b, although the current version is a very thin wrapper around the C runtime.

Eventually (i.e. when I finish GC), the GC will handle running any destructors on the stack, making unwinding unnecessary. I've got a partial patch at https://github.com/elliottslaughter/rust/commits/unique-ptrs, but it doesn't yet know about non-pointer resources on the stack.

[elliottslaughter]

This issue seems like a subset of #2861, yes?

Edit: No, actually. This involves language changes, whereas #2861 is only concerned with the runtime implementation.

[z0w0]

I think this is done now.

[catamorphism]

Done as of 172c29f