Rust should have an optional dependency on C++

[alexcrichton]

Right now, any compilation of any rust library will have a dependency on libstdc++. If one views Rust as a targeted replacement for C++, then it seems weird to depend on it!

There are currently four reasons why rust depends on C++

1. We use the new operator which I believe throws on OOM
2. We use statically initialized mutexes (statically run constructors)
3. We use exceptions to implement unwinding.
4. When linking librustrt, g++ is used instead of gcc

I have successfully extracted the dependency on C++ as part of alexcrichton@4b2bb6f. That patch is nowhere near a landable form, however.

I'm coming to believe that this is a fairly important dependency that we should be able to rid ourselves of (with strings attached). I propose the following plan of attack.

1. Complete Create bindings for native mutexes #9105
2. Remove all usage of static mutexes from C++ along with usage of the new operator
3. Move as many foo.cpp files to foo.c to prevent C++ from leaking in again.
4. Add a compilation profile to librustrt. This new profile would turn rust_try to just calling f, and rust_begin_unwind would be equivalent to assert(false). This new librustrt would be distributed along the rust standard libraries as librustrt_no_landing_pads or something like that.
5. When compiling with -Z no-landing-pads, link to librustrt_no_landing_pads instead of librustrt

As the strategy implies, the only way to drop the C++ dependency would be to forgo unwinding entirely. For now this is our best option of dropping the C++ dependency, and perhaps in the future if we ever implement unwinding without C++ exceptions we won't even need this business of a separate compilation profile.

How do others feel about this?

[thestinger]

Unwinding is implemented in libgcc_s and libsupc++ (often part of libstdc++) only exposes the C++ exception personality for it. There are plans to implement unwinding directly in the LLVM project, but it will probably only work on OS X at first. It already implements the C++ part of the equation with libc++abi but has to call out to libgcc_s on Linux and I guess with mingw too.

[alexcrichton]

Nominating. For embeddability of rust I believe that this is very important.

[alexcrichton]

Oh, I should also mention that our usage of the corresponding PERSONALITY_FUNC in rust_upcall.cpp is another dependence on libstdc++, but if we're not unwinding then this is fine to just omit.

[brson]

We need to ultimately completely rid ourselves of the C++ dependency, and I would rather achieve that than add a new build mode. Can we not unwind by using libunwind directly?

[alexcrichton]

Looking at libunwind's api, it looks like it's "really easy" to unwind the stack, but I don't think that it parses all the information to run destructors. I may be missing something, but that's the only piece for libunwind that I know of.

[pnkfelix]

Important long-term goal to get rid of C++ dependency, but does not block 1.0. P-low.