`rust_begin_unwind` not emitted when crate-type = bin

[japaric]

STR

$ cargo new --bin foo && cd $_

$ $EDITOR src/main.rs && cat $_

#![feature(panic_implementation)]
#![no_main]
#![no_std]

use core::panic::PanicInfo;

#[panic_implementation]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

$ # linking will fail but that's unimportant
$ cargo build --target thumbv7m-none-eabi
error: linking with `arm-none-eabi-gcc` failed: exit code: 1
  |
  = note: "arm-none-eabi-gcc" "-L" "$SYSROOT/lib/rustlib/thumbv7m-none-eabi/lib" "target/thumbv7m-none-eabi/debug/deps/foo-7e5b7587bde453e1.1y16o1qfye96o7m0.rcgu.o" (..)

$ nm -C target/thumbv7m-none-eabi/debug/deps/foo-7e5b7587bde453e1.1y16o1qfye96o7m0.rcgu.o && echo EMPTY
EMPTY

However if the crate is turned into an rlib the rust_begin_unwind symbol will be emitted.

$ mv src/{main,lib}.rs

$ cargo build --target thumbv7m-none-eabi

$ nm -C target/thumbv7m-none-eabi/debug/deps/libfoo-e1e65e68106e26e1.rlib

foo-e1e65e68106e26e1.1qddbosld5q76e2k.rcgu.o:
(..)
00000001 T rust_begin_unwind
00000000 t $t.0

Metada

$ rustc -V
rustc 1.28.0-nightly (523097979 2018-06-18)

However this problem is also present in nightly-2018-06-03 before #[panic_implementation] landed: rust_begin_unwind is not emitted when the panic_fmt lang item is present in a binary crate.

---

This issue was found while analyzing #51342 (comment).

[japaric]

I also see that the rust_eh_personality symbol is not emitted when the eh_personality lang item is present in the binary crate. eh_personality could also be affected by this bug, or this may actually be intentional. cc @alexcrichton do you know if this is a bug or intentional?

EDIT: same thing with rust_oom

[japaric]

Interesting. nightly-2017-06-01 does produce the rust_{begin_unwind,eh_personality} symbols, but nightly-2018-01-01 does not so this seems to be a regression.

[japaric]

After bisecting this: nightly-2017-11-08 worked but nightly-2017-11-09 didn't. The most relevant PR that landed between those two releases is #45575, which says:

For executables, cdylibs, and staticlibs, items are only exported if they are additionally #[no_mangle] or have an #[export_name].

It sounds like weak lang items should also be exported in this case as they are effectively #[no_mangle] symbols.

cc @michaelwoerister

[japaric]

fix in #51687